From wudxw at linux.vnet.ibm.com Mon Feb 4 13:52:50 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 04 Feb 2013 21:52:50 +0800 Subject: oVirt functional test suites Message-ID: <510FBD32.6020605@linux.vnet.ibm.com> Hi all, I am a vdsm developer. Recently I find there're many ongoing refactorings and improvements in vdsm code. From the bugs reported, we can see that unit tests just focus on a unit of code, and can't catch integration errors or broad system level errors. So we need a thorough functional test suites for vdsm. But the build environment is very limited to run functional tests. It has a lot of dependencies on the external setup, like storage server. I would like to know how the engine side perform functional tests. Is there any existing functional test suites based engine rest api? If yes, I think it's great to use it for vdsm's functional tests. We could build up a standard test env on physical machiness or vms for the test suites by some kickstart files. It also can be integrate into Jenkins. Any feedback will be appreciated! Mark. From ykaul at redhat.com Mon Feb 4 14:01:17 2013 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 04 Feb 2013 16:01:17 +0200 Subject: oVirt functional test suites In-Reply-To: <510FBD32.6020605@linux.vnet.ibm.com> References: <510FBD32.6020605@linux.vnet.ibm.com> Message-ID: <510FBF2D.5010608@redhat.com> On 04/02/13 15:52, Mark Wu wrote: > Hi all, > > I am a vdsm developer. Recently I find there're many ongoing > refactorings and improvements in vdsm code. From the bugs reported, we > can see that unit tests just focus on a unit of code, and can't catch > integration errors or broad system level errors. So we need a > thorough functional test suites for vdsm. But the build environment is > very limited to run functional tests. It has a lot of dependencies on > the external setup, like storage server. > > I would like to know how the engine side perform functional tests. Is > there any existing functional test suites based engine rest api? If > yes, I think it's great to use it for vdsm's functional tests. We > could build up a standard test env on physical machiness or vms for > the test suites by some kickstart files. It also can be integrate into > Jenkins. > > > Any feedback will be appreciated! > > Mark. > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch We've once published http://www.ovirt.org/Testing/PythonApi - but it was not maintained, and lacks a lot of building blocks. Y. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabiand at redhat.com Tue Feb 5 14:43:36 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 05 Feb 2013 15:43:36 +0100 Subject: oVirt functional test suites In-Reply-To: <510FBD32.6020605@linux.vnet.ibm.com> References: <510FBD32.6020605@linux.vnet.ibm.com> Message-ID: <1360075416.2527.9.camel@fdeutsch-laptop.local> Am Montag, den 04.02.2013, 21:52 +0800 schrieb Mark Wu: > Hi all, > > I am a vdsm developer. Recently I find there're many ongoing > refactorings and improvements in vdsm code. From the bugs reported, we > can see that unit tests just focus on a unit of code, and can't catch > integration errors or broad system level errors. So we need a thorough > functional test suites for vdsm. But the build environment is very > limited to run functional tests. It has a lot of dependencies on the > external setup, like storage server. > > I would like to know how the engine side perform functional tests. Is > there any existing functional test suites based engine rest api? If yes, > I think it's great to use it for vdsm's functional tests. We could build > up a standard test env on physical machiness or vms for the test suites > by some kickstart files. It also can be integrate into Jenkins. Hey, with oVirt Node we've had a similar problem. That functional tets required a running system (VM or real hardware). We've come up with igor [0], which prepares VMs or real systems using PXE and custom kernel arguments. Afterwards a client is run on the freshly created system to run our functional tests. Basically you can point igor to an ISO which is being booted using custom kernel arguments, so you should also be able to install RHEL or Fedora using this method (I've never tried it though ..). We've also integrated this tests into Jenkins (currently only run RH internal, b/c of upstream limitations [which might have changed by now]). Greetings fabian [0] https://gitorious.org/ovirt/igord -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From iheim at redhat.com Wed Feb 6 10:23:53 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Feb 2013 12:23:53 +0200 Subject: oVirt functional test suites In-Reply-To: <1360075416.2527.9.camel@fdeutsch-laptop.local> References: <510FBD32.6020605@linux.vnet.ibm.com> <1360075416.2527.9.camel@fdeutsch-laptop.local> Message-ID: <51122F39.6080004@redhat.com> On 05/02/2013 16:43, Fabian Deutsch wrote: > Am Montag, den 04.02.2013, 21:52 +0800 schrieb Mark Wu: >> Hi all, >> >> I am a vdsm developer. Recently I find there're many ongoing >> refactorings and improvements in vdsm code. From the bugs reported, we >> can see that unit tests just focus on a unit of code, and can't catch >> integration errors or broad system level errors. So we need a thorough >> functional test suites for vdsm. But the build environment is very >> limited to run functional tests. It has a lot of dependencies on the >> external setup, like storage server. >> >> I would like to know how the engine side perform functional tests. Is >> there any existing functional test suites based engine rest api? If yes, >> I think it's great to use it for vdsm's functional tests. We could build >> up a standard test env on physical machiness or vms for the test suites >> by some kickstart files. It also can be integrate into Jenkins. > > Hey, > > with oVirt Node we've had a similar problem. That functional tets > required a running system (VM or real hardware). We've come up with igor > [0], which prepares VMs or real systems using PXE and custom kernel > arguments. Afterwards a client is run on the freshly created system to > run our functional tests. Basically you can point igor to an ISO which > is being booted using custom kernel arguments, so you should also be > able to install RHEL or Fedora using this method (I've never tried it > though ..). > > We've also integrated this tests into Jenkins (currently only run RH > internal, b/c of upstream limitations [which might have changed by > now]). > > Greetings > fabian > > [0] https://gitorious.org/ovirt/igord > > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > I think we reached a point we need to add an environment capable of running system tests covering both engine and vdsm. From shaohef at linux.vnet.ibm.com Thu Feb 7 14:19:01 2013 From: shaohef at linux.vnet.ibm.com (Sheldon) Date: Thu, 07 Feb 2013 22:19:01 +0800 Subject: [vdsm] Review Request: dump the core of a VM. In-Reply-To: <5110E2D6.3040401@redhat.com> References: <5110DADD.1060900@linux.vnet.ibm.com> <5110E2D6.3040401@redhat.com> Message-ID: <5113B7D5.9060804@linux.vnet.ibm.com> On 02/05/2013 06:45 PM, Itamar Heim wrote: > On 05/02/2013 12:11, Sheldon wrote: >> Hi, all. >> >> There is a patch 'dump the core of a VM'. >> http://gerrit.ovirt.org/#/c/7329/ >> And this is the wiki page. http://www.ovirt.org/Features/vm_coredump >> >> I think the feature will be useful when used with high availability >> >> VDSM users can dump core of their VMs manually, when the find the VMs >> crash or they receive a watchdog event report. >> >> > > thanks for the ping. > why not sent to arch mailing list for review/comments on the feature > page? > > some thoughts (better replied on a thread on arch mailing list) > I'm assuming limited to admins, not users. Yes, agree. > how dumps gets collected from host? cleaned to not use all space? is > space checked before dumping? how is path of dump determined (maybe > should be dumped to the export domain rather than to host, though more > complex) IMHO, to an export domain is better to host. for the dumps API, the file name must be assigned. It can be a nfs path. -- Sheldon Feng(???) IBM Linux Technology Center From asegurap at redhat.com Thu Feb 7 22:54:23 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Thu, 7 Feb 2013 17:54:23 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <1493108470.6901673.1360276395740.JavaMail.root@redhat.com> Message-ID: <999203743.6904373.1360277663937.JavaMail.root@redhat.com> Hi fellow oVirters! The network team and a few others have toyed in the past with several important changes like using open vSwitch, talking D-BUS to NM, making the network non-persistent, etc. It is with some of this changes in mind that we (special thanks go to Livnat Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for a new architecture for vdsm's networking part. This proposal is intended to make our software more adaptable to new components and use cases, eliminate distro dependancies as much as possible and improve the responsiveness and scalability of the networking operations. To do so, it proposes an object oriented representation of the different elements that come into play in our networking use cases. But enough of introduction, please go to the feature page that we have put together and help us with your feedback, questions proposals and extensions. http://www.ovirt.org/Feature/NetworkReloaded Best regards, Toni From asegurap at redhat.com Fri Feb 8 16:49:05 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Fri, 8 Feb 2013 11:49:05 -0500 (EST) Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <1360317053.29407.1461.camel@dhcp-29-7.brq.redhat.com> Message-ID: <1315999312.7059811.1360342145086.JavaMail.root@redhat.com> Thanks for the feedback David. ----- Original Message ----- > From: "David Ja?a" > To: arch at ovirt.org, vdsm-devel at fedorahosted.org > Sent: Friday, February 8, 2013 10:50:53 AM > Subject: Re: [vdsm] vdsm networking changes proposal > > Hi, > > > Bridges: via the "brctl" cmdline tool. > > I was told that the canonical way to configure bridges in recent > distros > is also ip(8): > # ip link add br0 type bridge > # ip link set eth0 master br0 > # ip link set eth0 nomaster > > (RHEL6 still has to rely on brctl, though) For F18+ and RHEL7 I think that this point makes a lot of sense, that we should use ip link instead of brctl. Additionally, as the libnl3 python bindings mature, it would naturally lead to use that instead of iproute2 tools. > > > Alias > > * Users have shown interest in the likes of eth0:4. We should > > find out if this is really required of oVirt. > > If you consider ipfwadm support (Linux 2.0 feature also replaced in > 2.2 > with something else), go on. > > net-tools only pretend to work (add ip to a device via ip(8) or > direct > kernel cals and try to find corresponding alias for instance...) so > we > shouldn't contribute to life support of them. > > David > > > Antoni Segura Puimedon p??e v ?t 07. 02. 2013 v 17:54 -0500: > > Hi fellow oVirters! > > > > The network team and a few others have toyed in the past with > > several important > > changes like using open vSwitch, talking D-BUS to NM, making the > > network > > non-persistent, etc. > > > > It is with some of this changes in mind that we (special thanks go > > to Livnat > > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal > > for > > a new architecture for vdsm's networking part. This proposal is > > intended to > > make our software more adaptable to new components and use cases, > > eliminate > > distro dependancies as much as possible and improve the > > responsiveness and > > scalability of the networking operations. > > > > To do so, it proposes an object oriented representation of the > > different > > elements that come into play in our networking use cases. > > > > But enough of introduction, please go to the feature page that we > > have put > > together and help us with your feedback, questions proposals and > > extensions. > > > > http://www.ovirt.org/Feature/NetworkReloaded > > > > > > Best regards, > > > > Toni > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel at lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From iheim at redhat.com Fri Feb 8 07:26:46 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 08 Feb 2013 09:26:46 +0200 Subject: [vdsm] Review Request: dump the core of a VM. In-Reply-To: <5113B7D5.9060804@linux.vnet.ibm.com> References: <5110DADD.1060900@linux.vnet.ibm.com> <5110E2D6.3040401@redhat.com> <5113B7D5.9060804@linux.vnet.ibm.com> Message-ID: <5114A8B6.8060709@redhat.com> On 07/02/2013 16:19, Sheldon wrote: > On 02/05/2013 06:45 PM, Itamar Heim wrote: >> On 05/02/2013 12:11, Sheldon wrote: >>> Hi, all. >>> >>> There is a patch 'dump the core of a VM'. >>> http://gerrit.ovirt.org/#/c/7329/ >>> And this is the wiki page. http://www.ovirt.org/Features/vm_coredump >>> >>> I think the feature will be useful when used with high availability >>> >>> VDSM users can dump core of their VMs manually, when the find the VMs >>> crash or they receive a watchdog event report. >>> >>> >> >> thanks for the ping. >> why not sent to arch mailing list for review/comments on the feature >> page? >> >> some thoughts (better replied on a thread on arch mailing list) >> I'm assuming limited to admins, not users. > Yes, agree. >> how dumps gets collected from host? cleaned to not use all space? is >> space checked before dumping? how is path of dump determined (maybe >> should be dumped to the export domain rather than to host, though more >> complex) > IMHO, to an export domain is better to host. > for the dumps API, the file name must be assigned. It can be a nfs path. so if no export domain, dump fails. (i guess i can live with that). From ilvovsky at redhat.com Sun Feb 10 09:49:21 2013 From: ilvovsky at redhat.com (Igor Lvovsky) Date: Sun, 10 Feb 2013 04:49:21 -0500 (EST) Subject: feature suggestion: migration network In-Reply-To: <50FFDC23.1080009@redhat.com> Message-ID: <185176614.192345.1360489761726.JavaMail.root@redhat.com> Hi, I would like to summarize migration network discussion. Please refer to wiki page http://www.ovirt.org/Features/Migration_Network for more details Regards, Igor Lvovsky > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From msalem at redhat.com Sun Feb 10 13:25:00 2013 From: msalem at redhat.com (Muli Salem) Date: Sun, 10 Feb 2013 08:25:00 -0500 (EST) Subject: Direct Host Address In-Reply-To: <31078904.128.1360502354599.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> Message-ID: <32846495.141.1360502626228.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> Hi All, Below please find a short wiki page regarding the Direct Host Address feature, which will allow the admin to define a separate "direct" IP address on a host, for SSH purposes only. http://www.ovirt.org/Features/DirectHostAddress Would love to here your comments. Thanks, Muli From ykaul at redhat.com Sun Feb 10 14:37:43 2013 From: ykaul at redhat.com (Yaniv Kaul) Date: Sun, 10 Feb 2013 16:37:43 +0200 Subject: Direct Host Address In-Reply-To: <32846495.141.1360502626228.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> References: <32846495.141.1360502626228.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> Message-ID: <5117B0B7.3000409@redhat.com> On 10/02/13 15:25, Muli Salem wrote: > Hi All, > > Below please find a short wiki page regarding the Direct Host Address feature, which will allow the admin to define a separate "direct" IP address on a host, for SSH purposes only. > > http://www.ovirt.org/Features/DirectHostAddress 'Alternate Install IP' sounds like a better feature name (also in the UI). Y. > > Would love to here your comments. > > Thanks, > Muli > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From yzaslavs at redhat.com Sun Feb 10 14:48:19 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 10 Feb 2013 09:48:19 -0500 (EST) Subject: Direct Host Address In-Reply-To: <5117B0B7.3000409@redhat.com> Message-ID: <629890719.165558.1360507699142.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yaniv Kaul" > To: "Muli Salem" > Cc: arch at ovirt.org > Sent: Sunday, February 10, 2013 4:37:43 PM > Subject: Re: Direct Host Address > > On 10/02/13 15:25, Muli Salem wrote: > > Hi All, > > > > Below please find a short wiki page regarding the Direct Host > > Address feature, which will allow the admin to define a separate > > "direct" IP address on a host, for SSH purposes only. > > > > http://www.ovirt.org/Features/DirectHostAddress > > 'Alternate Install IP' sounds like a better feature name (also in the > UI). > Y. > > > > > Would love to here your comments. > > > > Thanks, > > Muli Please provide DB changes information (probably vds_static, but I'm only assuming :) ) > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From msalem at redhat.com Sun Feb 10 14:55:22 2013 From: msalem at redhat.com (Muli Salem) Date: Sun, 10 Feb 2013 09:55:22 -0500 (EST) Subject: Direct Host Address In-Reply-To: <629890719.165558.1360507699142.JavaMail.root@redhat.com> Message-ID: <6324792.167.1360508050791.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Yaniv Kaul" > Cc: arch at ovirt.org, "Muli Salem" > Sent: Sunday, 10 February, 2013 4:48:19 PM > Subject: Re: Direct Host Address > > > > ----- Original Message ----- > > From: "Yaniv Kaul" > > To: "Muli Salem" > > Cc: arch at ovirt.org > > Sent: Sunday, February 10, 2013 4:37:43 PM > > Subject: Re: Direct Host Address > > > > On 10/02/13 15:25, Muli Salem wrote: > > > Hi All, > > > > > > Below please find a short wiki page regarding the Direct Host > > > Address feature, which will allow the admin to define a separate > > > "direct" IP address on a host, for SSH purposes only. > > > > > > http://www.ovirt.org/Features/DirectHostAddress > > > > 'Alternate Install IP' sounds like a better feature name (also in > > the > > UI). > > Y. Thanks, maybe "Alternate Installation IP". > > > > > > > > Would love to here your comments. > > > > > > Thanks, > > > Muli > > Please provide DB changes information (probably vds_static, but I'm > only assuming :) ) Actually, there is no need for DB changes. The address is only needed for installation, therefore will be given as a parameter for the action (add/reinstall host). > > > > _______________________________________________ > > > Arch mailing list > > > Arch at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > From mkolesni at redhat.com Sun Feb 10 15:26:42 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 10 Feb 2013 10:26:42 -0500 (EST) Subject: Direct Host Address In-Reply-To: <32846495.141.1360502626228.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> Message-ID: <760537720.99234.1360510002991.JavaMail.root@redhat.com> ----- Original Message ----- > Hi All, > > Below please find a short wiki page regarding the Direct Host Address > feature, which will allow the admin to define a separate "direct" IP > address on a host, for SSH purposes only. > > http://www.ovirt.org/Features/DirectHostAddress > > Would love to here your comments. Hi Muli, Sounds good overall, here are my comments: In 'Detailed Description': "When adding a host, admin sets the host address. The engine uses this address to manage the host in two ways. The first is via SSH for host installation, and the second is via xml-rpc for any other action." What do you mean "the second is via xml-rpc"..? What commands will go over this channel? "Current behaviour assumes the network interface with the specified address is configured properly in the engine although this may not be the case initially" I don't understand what does this mean, which interface are you referring to and what does it have to do with being configured in the engine? The next line is also unclear to me: "The direct address allows the engine to connect to the host, without knowing the exact configuration of the network interface that has the address. " In 'Motivation': "To allow another route to the host to a network interface other than the one used for the management network, since that network interface may need to be configured in the engine first." I would say simply that the management traffic might go over a channel which requires connectivity (e.g. VLAN) with the engine to be established prior to being able to communicate with the host. > > Thanks, > Muli > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From msalem at redhat.com Sun Feb 10 16:09:30 2013 From: msalem at redhat.com (Muli Salem) Date: Sun, 10 Feb 2013 11:09:30 -0500 (EST) Subject: Direct Host Address In-Reply-To: <760537720.99234.1360510002991.JavaMail.root@redhat.com> Message-ID: <10509509.227.1360512495456.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "Muli Salem" > Cc: arch at ovirt.org > Sent: Sunday, 10 February, 2013 5:26:42 PM > Subject: Re: Direct Host Address > > ----- Original Message ----- > > Hi All, > > > > Below please find a short wiki page regarding the Direct Host > > Address > > feature, which will allow the admin to define a separate "direct" > > IP > > address on a host, for SSH purposes only. > > > > http://www.ovirt.org/Features/DirectHostAddress > > > > Would love to here your comments. > > Hi Muli, > > Sounds good overall, here are my comments: > > In 'Detailed Description': > > "When adding a host, admin sets the host address. The engine uses > this address to manage the host in two ways. The first is via SSH > for host installation, and the second is via xml-rpc for any other > action." > > What do you mean "the second is via xml-rpc"..? What commands will go > over this channel? Except for host installation, all other communication between engine and host (for example, VdsCommands). > > "Current behaviour assumes the network interface with the specified > address is configured properly in the engine although this may not > be the case initially" > > I don't understand what does this mean, which interface are you > referring to and what does it have to do with being configured in > the engine? > The next line is also unclear to me: > "The direct address allows the engine to connect to the host, without > knowing the exact configuration of the network interface that has > the address. " > Regarding the last two sentences you quoted: I am referring to the interface that has the IP that the user gives us (with regards to current behavior). At the moment, we assume that the given IP is for an interface that can communicate with the engine (when in practice, this may not be the case). So separating the two addresses, allows us to ask the admin for an alternate IP address that will allow communication without needing to know the specific configuration (for example, whether this is a VLAN network or not). Perhaps the wording should be changed a bit to clarify. > In 'Motivation': > > "To allow another route to the host to a network interface other than > the one used for the management network, since that network > interface may need to be configured in the engine first." > > I would say simply that the management traffic might go over a > channel which requires connectivity (e.g. VLAN) with the engine to > be established prior to being able to communicate with the host. > Not quite sure I see a noteworthy difference between the two sentences. > > > > > Thanks, > > Muli > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > From mkolesni at redhat.com Sun Feb 10 16:36:39 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 10 Feb 2013 11:36:39 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <999203743.6904373.1360277663937.JavaMail.root@redhat.com> Message-ID: <1974789474.101985.1360514199067.JavaMail.root@redhat.com> Hi Antoni, Regarding 'Bond' how is it logical to have VLANs as slaves? Is it something we would like to support, or just be able to represent, if we ever come across this odd combination? Also, can bond slaves have ipConfig set? Regarding 'VLAN' is it possible to have the VLAN over bridge as you written? I'm not sure if that's something supported currently, but is there a plan to support this mode? Generally seems like these entities have a lot in common that can be in a common 'interface' entity. Also for OVS I don't understand if the current model will be extensible to support for example GRE tunnels, which aren't necessarily supported in other configurers. Regards, Mike ----- Original Message ----- > Hi fellow oVirters! > > The network team and a few others have toyed in the past with several > important > changes like using open vSwitch, talking D-BUS to NM, making the > network > non-persistent, etc. > > It is with some of this changes in mind that we (special thanks go to > Livnat > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for > a new architecture for vdsm's networking part. This proposal is > intended to > make our software more adaptable to new components and use cases, > eliminate > distro dependancies as much as possible and improve the > responsiveness and > scalability of the networking operations. > > To do so, it proposes an object oriented representation of the > different > elements that come into play in our networking use cases. > > But enough of introduction, please go to the feature page that we > have put > together and help us with your feedback, questions proposals and > extensions. > > http://www.ovirt.org/Feature/NetworkReloaded > > > Best regards, > > Toni > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From mpastern at redhat.com Tue Feb 12 11:10:37 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 12 Feb 2013 13:10:37 +0200 Subject: Direct Host Address In-Reply-To: <5117B0B7.3000409@redhat.com> References: <32846495.141.1360502626228.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> <5117B0B7.3000409@redhat.com> Message-ID: <511A232D.3040707@redhat.com> On 02/10/2013 04:37 PM, Yaniv Kaul wrote: > On 10/02/13 15:25, Muli Salem wrote: >> Hi All, >> >> Below please find a short wiki page regarding the Direct Host Address feature, which will allow the admin to define a separate "direct" IP address on a host, for SSH >> purposes only. >> >> http://www.ovirt.org/Features/DirectHostAddress > > 'Alternate Install IP' sounds like a better feature name (also in the UI). > Y. the name is not clear indeed, if it's for SSH only, "ssh_channel" ? > >> >> Would love to here your comments. >> >> Thanks, >> Muli >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed Feb 13 10:55:36 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 13 Feb 2013 12:55:36 +0200 Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <511A6A39.2090706@redhat.com> References: <511A6A39.2090706@redhat.com> Message-ID: <511B7128.3030703@redhat.com> Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --------------------------------------------------- pros ==== - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2] cons ==== - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK -------- pros ==== - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons ==== - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl On 02/12/2013 06:13 PM, Libor Spevak wrote: > Hi, > > I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to > Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects > and the server-side logic can duplicate. > > Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a > little bit different, but something overlaps. > > I found several links about REST API support from GWT, so there is something for inspiration... > > - http://www.spiffyui.org/ > - http://www.zackgrossbart.com/hackito/gwt-rest/ > - http://code.google.com/p/gwt-rest/ > - http://restygwt.fusesource.org/ > > But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful > refactoring, ...)? > > Regards, > Libor > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From dneary at redhat.com Wed Feb 13 11:39:55 2013 From: dneary at redhat.com (Dave Neary) Date: Wed, 13 Feb 2013 12:39:55 +0100 Subject: Concerning Loadays 2013 In-Reply-To: <20130116203816.GA29953@faramir.homebase.local> References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org> <50CB3D3B.1040205@redhat.com> <20121215094410.GB3314@faramir.homebase.local> <50D0EEF5.6030303@redhat.com> <20130116203816.GA29953@faramir.homebase.local> Message-ID: <511B7B8B.6050303@redhat.com> Hi everyone, This invitation is still outstanding, and I would love to see an oVirt presentation at the conference. Unfortunately, I am already sure I will not be able to attend, the dates do not work for me. So I am looking for a brave volunteer in Europe, preferably near Antwerp, to give a presentation on oVirt for an audience of sysadmins and DevOps. I'll be happy to help you with the slides and the presentation content beforehand! Please let me know (on list preferably, but off list if you're shy and I'll let people know here I have a volunteer) before the opportunity passes us by. Vincent, thank you for your patience! Regards, Dave. On 01/16/2013 09:38 PM, Vincent Van der Kussen wrote: > On Wed, Dec 19, 2012 at 12:32:21AM +0200, Itamar Heim wrote: >> On 12/15/2012 11:44 AM, Vincent Van der Kussen wrote: >>> On Fri, Dec 14, 2012 at 03:52:43PM +0100, Dave Neary wrote: >>> >>> Hi, >>> >>> >>>> Hi, >>>> >>>> I would love to see us have a speaker at this conference. >>>> >>>> Vincent, what is the level of the audience usually? Would the >>>> audience be more interested in an "overview of oVirt"? or more >>>> community outreach ("how to get involved")? >>> >>> Most people are active in several open source projects and have a technical background. >>> So a more in depth and practical overview + how to participate in the oVirt community would cover it. >>> There's always place (depending on the other talks/workshops of course) to do a workshop to show >>> the technical/practical side of oVirt. >>> >>> I think most people would like to know more about how oVirt handles storage, networking, does Gluster work?, etc.. >>>> >>>> I can think of a few potential speakers, if they're willing to >>>> try... Ewoud is the nearest community member to Brussels, but I am >>>> also very close. >>>> >>>> When is the deadline for proposals? >>> >>> Deadline is arounf 1st of March. >>> >>> If you have any further questions you can always contact me. >> >> sounds interesting, are you looking for 1-2 sessions, or more than >> that (intro, arch, ovirt-live hands-on session, etc.)? >> >> thanks, >> Itamar > > Hi, > > FYI : the CFP is open until mid of March. > info at http://www.loadays.org > > Regards, > Vincent > >> >> -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From masayag at redhat.com Wed Feb 13 23:43:55 2013 From: masayag at redhat.com (Moti Asayag) Date: Thu, 14 Feb 2013 01:43:55 +0200 Subject: feature suggestion: migration network In-Reply-To: <185176614.192345.1360489761726.JavaMail.root@redhat.com> References: <185176614.192345.1360489761726.JavaMail.root@redhat.com> Message-ID: <511C253B.9030405@redhat.com> On 02/10/2013 11:49 AM, Igor Lvovsky wrote: > Hi, > I would like to summarize migration network discussion. > Please refer to wiki page http://www.ovirt.org/Features/Migration_Network > for more details > 1. Could you explain the motivation of not setting the migration role when migration is running ? "The "migration" role can be granted or taken on-the-fly, when hosts are active, as long as there are no currently-migrating VMs. " 2. dstqemu - should the engine send the migration network ip or the migration network name and let vdsm resolves the address ? 3. Error handling: regarding the unpleasant surprise of an attempt to migrate a VM to a host which doesn't have the migration network - any new error should be received from vdsm for that ? 4. Could we get to a point in which we don't have a network with a migration role ? We can rely on the management network, but what if network 'red' was selected to be a migration network and now it is being deleted? As i see it there are 3 options: 1. We block the operation and ask to select other migration network. 2. We automatically define the management network as the migration network. 3. We do nothing. On VM migration we'll analyse the migration network (dynamically select the default network). > Regards, > Igor Lvovsky > >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From dfediuck at redhat.com Thu Feb 14 09:20:00 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 14 Feb 2013 04:20:00 -0500 (EST) Subject: REST API calls from (was: REST API calls from the GUI) In-Reply-To: <511B7128.3030703@redhat.com> Message-ID: <82414620.2634605.1360833600485.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Libor Spevak" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Wednesday, February 13, 2013 12:55:36 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > > Hi Libor, > > This issue came across in one of the conversations i had with UX > folks, but since we didn't end > up with any conclusion/road map (nor discussed it properly to hear > other thoughts), this is a perfect > place to start this discussion, > > Intuitively REST is a way to go with GWT AJAX calls > --------------------------------------------------- > > pros > ==== > > - api data objects can be reused by generating java classes (using > jaxb) from the rest schema [1] > - no backend logic will be duplicated as api abstracts the backend > exposing RESTful collection/resources to operate on > - development against api is "easy" as api describes itself in RSDL > [2] > > cons > ==== > > - implementing transport layer (HTTP) under GWT > - implementing own j2xml/json/yaml/... marshalling layer > - implementing own error handling mechanism > - implementing REST callback mechanism (in GWT) > - constant maintenance of the data objects generated from the api > - painful for Java developers > > Java-SDK > -------- > > pros > ==== > > - abstracts transport layer (leaving developer in standard Java api) > - typesafe code (no need to mess with XML bulks) > - has own data objects to work with > - abstracts authentication/authorization > (kerberos/cookie/session/etc.) > - since SDK is auto-generated, it can be easily extended with > required > features to support UI (such as callback infrastructure for > instance) > > cons > ==== > > - has to be converted in to Javascript (not sure what the impacts are > in terms of AJAX calls/etc.) > - probably much more cons that we're not aware of and will have to > figure out with POC > > > thoughts? > > [1] http[s]://server[:port]/api?schema > [2] http[s]://server[:port]/api?rsdl > Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? > On 02/12/2013 06:13 PM, Libor Spevak wrote: > > Hi, > > > > I would like to ask, if there have been discussions about an option > > to call REST API services directly from the Frontend (GWT layer)? > > GWT compiles Java frontend-side to > > Javascript, calls to backend services are performed "transparently" > > by the framework using AJAX support. But, there is still a need to > > have a special set of data objects > > and the server-side logic can duplicate. > > > > Java REST API SDK enables to build "thick" client. The calls are > > realized using e.g. Apache HttClient and supported libraries. I > > think the requirements of GWT can be a > > little bit different, but something overlaps. > > > > I found several links about REST API support from GWT, so there is > > something for inspiration... > > > > - http://www.spiffyui.org/ > > - http://www.zackgrossbart.com/hackito/gwt-rest/ > > - http://code.google.com/p/gwt-rest/ > > - http://restygwt.fusesource.org/ > > > > But, do you think it would be useful and what drawbacks can occur > > (authentication, authorization, response times, need to support > > larger set of services, painful > > refactoring, ...)? > > > > Regards, > > Libor > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From danken at redhat.com Thu Feb 14 09:46:34 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 14 Feb 2013 11:46:34 +0200 Subject: feature suggestion: migration network In-Reply-To: <511C253B.9030405@redhat.com> References: <185176614.192345.1360489761726.JavaMail.root@redhat.com> <511C253B.9030405@redhat.com> Message-ID: <20130214094633.GC23843@redhat.com> On Thu, Feb 14, 2013 at 01:43:55AM +0200, Moti Asayag wrote: > On 02/10/2013 11:49 AM, Igor Lvovsky wrote: > > Hi, > > I would like to summarize migration network discussion. > > Please refer to wiki page http://www.ovirt.org/Features/Migration_Network > > for more details > > > > 1. Could you explain the motivation of not setting the migration role > when migration is running ? > "The "migration" role can be granted or taken on-the-fly, when hosts are > active, as long as there are no currently-migrating VMs. " The intention was to avoid an incoherence between currently-migrating VMs, which are using the old migration network, and the newly-defined network. People should be aware that you cannot change the effective migration network of a VM while it is migrating. However, this idea has the drawback of starvation: withing a big cluster with many VMs, one VM is bound to be running when you want to change the migration network. Thus I'm inclined to drop this requirement. However we should make it clear that any change to migration network affects only future migrations. > 2. dstqemu - should the engine send the migration network ip or the > migration network name and let vdsm resolves the address ? According to the suggested API, Engine sends the ip address of the migration network on destination host. The recipient of the verb (source vdsm) would have harder time figuring it out. > > 3. Error handling: regarding the unpleasant surprise of an attempt to > migrate a VM to a host which doesn't have the migration network - any > new error should be received from vdsm for that ? Vdsm would find out the problem asynchronously. Does engine poll getMigrationStatus on the source host when migration fails? If it does we could invent a new error code for that. > > 4. Could we get to a point in which we don't have a network with a > migration role ? We can rely on the management network, but what if > network 'red' was selected to be a migration network and now it is being > deleted? As i see it there are 3 options: > 1. We block the operation and ask to select other migration network. > 2. We automatically define the management network as the migration network. > 3. We do nothing. On VM migration we'll analyse the migration network > (dynamically select the default network). I prefer (3), to fall back to the management network as late as possible. Frankly, I think that it would be nice to fall back to the old API, of not sending dstqemu at all - we should have this logic anyway for old cluster levels. If someone recreate "red", we avoid the needless jitter suggested by (2). Dan. From alonbl at redhat.com Thu Feb 14 20:27:57 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Feb 2013 15:27:57 -0500 (EST) Subject: Direct Host Address In-Reply-To: <10509509.227.1360512495456.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> Message-ID: <1959466485.1085341.1360873677105.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Muli Salem" > To: "Mike Kolesnik" > Cc: arch at ovirt.org > Sent: Sunday, February 10, 2013 6:09:30 PM > Subject: Re: Direct Host Address > > > > "Current behaviour assumes the network interface with the specified > > address is configured properly in the engine although this may not > > be the case initially" > > > > I don't understand what does this mean, which interface are you > > referring to and what does it have to do with being configured in > > the engine? > > The next line is also unclear to me: > > "The direct address allows the engine to connect to the host, > > without > > knowing the exact configuration of the network interface that has > > the address. " > > > > Regarding the last two sentences you quoted: > > I am referring to the interface that has the IP that the user gives > us (with regards to current behavior). > At the moment, we assume that the given IP is for an interface that > can communicate with the engine (when in practice, this may not be > the case). > So separating the two addresses, allows us to ask the admin for an > alternate IP address that will allow communication without needing > to know the specific configuration (for example, whether this is a > VLAN network or not). > > Perhaps the wording should be changed a bit to clarify. I still don't get it... can you please provide real world use case? When can we access the alternate address and not the management address? Thanks, Alon From derez at redhat.com Fri Feb 15 18:17:43 2013 From: derez at redhat.com (Daniel Erez) Date: Fri, 15 Feb 2013 13:17:43 -0500 (EST) Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <511B7128.3030703@redhat.com> Message-ID: <470070335.2218501.1360952263800.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Libor Spevak" > Cc: engine-devel at ovirt.org, "Daniel Erez" , "Gilad Chaplik" , "Einav Cohen" > , arch at ovirt.org > Sent: Wednesday, February 13, 2013 12:55:36 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > > Hi Libor, > > This issue came across in one of the conversations i had with UX > folks, but since we didn't end > up with any conclusion/road map (nor discussed it properly to hear > other thoughts), this is a perfect > place to start this discussion, > > Intuitively REST is a way to go with GWT AJAX calls > --------------------------------------------------- > > pros > ==== > > - api data objects can be reused by generating java classes (using > jaxb) from the rest schema [1] > - no backend logic will be duplicated as api abstracts the backend > exposing RESTful collection/resources to operate on > - development against api is "easy" as api describes itself in RSDL > [2] > > cons > ==== > > - implementing transport layer (HTTP) under GWT > - implementing own j2xml/json/yaml/... marshalling layer > - implementing own error handling mechanism > - implementing REST callback mechanism (in GWT) > - constant maintenance of the data objects generated from the api > - painful for Java developers > > Java-SDK > -------- > > pros > ==== > > - abstracts transport layer (leaving developer in standard Java api) > - typesafe code (no need to mess with XML bulks) > - has own data objects to work with > - abstracts authentication/authorization > (kerberos/cookie/session/etc.) > - since SDK is auto-generated, it can be easily extended with > required > features to support UI (such as callback infrastructure for > instance) > > cons > ==== > > - has to be converted in to Javascript (not sure what the impacts are > in terms of AJAX calls/etc.) > - probably much more cons that we're not aware of and will have to > figure out with POC > > > thoughts? The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > > [1] http[s]://server[:port]/api?schema > [2] http[s]://server[:port]/api?rsdl > > On 02/12/2013 06:13 PM, Libor Spevak wrote: > > Hi, > > > > I would like to ask, if there have been discussions about an option > > to call REST API services directly from the Frontend (GWT layer)? > > GWT compiles Java frontend-side to > > Javascript, calls to backend services are performed "transparently" > > by the framework using AJAX support. But, there is still a need to > > have a special set of data objects > > and the server-side logic can duplicate. > > > > Java REST API SDK enables to build "thick" client. The calls are > > realized using e.g. Apache HttClient and supported libraries. I > > think the requirements of GWT can be a > > little bit different, but something overlaps. > > > > I found several links about REST API support from GWT, so there is > > something for inspiration... > > > > - http://www.spiffyui.org/ > > - http://www.zackgrossbart.com/hackito/gwt-rest/ > > - http://code.google.com/p/gwt-rest/ > > - http://restygwt.fusesource.org/ > > > > But, do you think it would be useful and what drawbacks can occur > > (authentication, authorization, response times, need to support > > larger set of services, painful > > refactoring, ...)? > > > > Regards, > > Libor > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From vszocs at redhat.com Fri Feb 15 19:37:56 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 15 Feb 2013 14:37:56 -0500 (EST) Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <470070335.2218501.1360952263800.JavaMail.root@redhat.com> Message-ID: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com> Hi Daniel, > The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) > and GWT overlay types (that can be generated from java POJOs). > Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. > The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is > (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced > with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types). > A third alternative could be simply maintaining the current GWT RPC mechanism we use. > I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. > The main drawback is an additional layer of data type conversion and round-trip: > Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved. Vojtech ----- Original Message ----- From: "Daniel Erez" To: "Michael Pasternak" Cc: engine-devel at ovirt.org, "Einav Cohen" , arch at ovirt.org, "Libor Spevak" , "Vojtech Szocs" Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI ----- Original Message ----- > From: "Michael Pasternak" > To: "Libor Spevak" > Cc: engine-devel at ovirt.org, "Daniel Erez" , "Gilad Chaplik" , "Einav Cohen" > , arch at ovirt.org > Sent: Wednesday, February 13, 2013 12:55:36 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > > Hi Libor, > > This issue came across in one of the conversations i had with UX > folks, but since we didn't end > up with any conclusion/road map (nor discussed it properly to hear > other thoughts), this is a perfect > place to start this discussion, > > Intuitively REST is a way to go with GWT AJAX calls > --------------------------------------------------- > > pros > ==== > > - api data objects can be reused by generating java classes (using > jaxb) from the rest schema [1] > - no backend logic will be duplicated as api abstracts the backend > exposing RESTful collection/resources to operate on > - development against api is "easy" as api describes itself in RSDL > [2] > > cons > ==== > > - implementing transport layer (HTTP) under GWT > - implementing own j2xml/json/yaml/... marshalling layer > - implementing own error handling mechanism > - implementing REST callback mechanism (in GWT) > - constant maintenance of the data objects generated from the api > - painful for Java developers > > Java-SDK > -------- > > pros > ==== > > - abstracts transport layer (leaving developer in standard Java api) > - typesafe code (no need to mess with XML bulks) > - has own data objects to work with > - abstracts authentication/authorization > (kerberos/cookie/session/etc.) > - since SDK is auto-generated, it can be easily extended with > required > features to support UI (such as callback infrastructure for > instance) > > cons > ==== > > - has to be converted in to Javascript (not sure what the impacts are > in terms of AJAX calls/etc.) > - probably much more cons that we're not aware of and will have to > figure out with POC > > > thoughts? The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > > [1] http[s]://server[:port]/api?schema > [2] http[s]://server[:port]/api?rsdl > > On 02/12/2013 06:13 PM, Libor Spevak wrote: > > Hi, > > > > I would like to ask, if there have been discussions about an option > > to call REST API services directly from the Frontend (GWT layer)? > > GWT compiles Java frontend-side to > > Javascript, calls to backend services are performed "transparently" > > by the framework using AJAX support. But, there is still a need to > > have a special set of data objects > > and the server-side logic can duplicate. > > > > Java REST API SDK enables to build "thick" client. The calls are > > realized using e.g. Apache HttClient and supported libraries. I > > think the requirements of GWT can be a > > little bit different, but something overlaps. > > > > I found several links about REST API support from GWT, so there is > > something for inspiration... > > > > - http://www.spiffyui.org/ > > - http://www.zackgrossbart.com/hackito/gwt-rest/ > > - http://code.google.com/p/gwt-rest/ > > - http://restygwt.fusesource.org/ > > > > But, do you think it would be useful and what drawbacks can occur > > (authentication, authorization, response times, need to support > > larger set of services, painful > > refactoring, ...)? > > > > Regards, > > Libor > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From mpastern at redhat.com Sun Feb 17 09:01:09 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 17 Feb 2013 11:01:09 +0200 Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com> References: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com> Message-ID: <51209C55.90400@redhat.com> On 02/15/2013 09:37 PM, Vojtech Szocs wrote: > Hi Daniel, > >> > The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) >> > and GWT overlay types (that can be generated from java POJOs). >> > Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. > Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. REST API does not support JSON yet due to Resteasy JacksonProvider and JAXB issues. > -- Michael Pasternak RedHat, ENG-Virtualization R&D From danken at redhat.com Sun Feb 17 10:44:02 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Sun, 17 Feb 2013 12:44:02 +0200 Subject: Direct Host Address In-Reply-To: <1959466485.1085341.1360873677105.JavaMail.root@redhat.com> References: <10509509.227.1360512495456.JavaMail.msalem@dhcp-1-23.tlv.redhat.com> <1959466485.1085341.1360873677105.JavaMail.root@redhat.com> Message-ID: <20130217104402.GG23843@redhat.com> On Thu, Feb 14, 2013 at 03:27:57PM -0500, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Muli Salem" > > To: "Mike Kolesnik" > > Cc: arch at ovirt.org > > Sent: Sunday, February 10, 2013 6:09:30 PM > > Subject: Re: Direct Host Address > > > > > > "Current behaviour assumes the network interface with the specified > > > address is configured properly in the engine although this may not > > > be the case initially" > > > > > > I don't understand what does this mean, which interface are you > > > referring to and what does it have to do with being configured in > > > the engine? > > > The next line is also unclear to me: > > > "The direct address allows the engine to connect to the host, > > > without > > > knowing the exact configuration of the network interface that has > > > the address. " > > > > > > > Regarding the last two sentences you quoted: > > > > I am referring to the interface that has the IP that the user gives > > us (with regards to current behavior). > > At the moment, we assume that the given IP is for an interface that > > can communicate with the engine (when in practice, this may not be > > the case). > > So separating the two addresses, allows us to ask the admin for an > > alternate IP address that will allow communication without needing > > to know the specific configuration (for example, whether this is a > > VLAN network or not). > > > > Perhaps the wording should be changed a bit to clarify. > > I still don't get it... can you please provide real world use case? > > When can we access the alternate address and not the management address? We have customers who want to install vdsm via native connection, but manage it over a VLAN. If you want to add a fresh host, you cannot use its management address (that sits inside the vlan). From alonbl at redhat.com Sun Feb 17 11:12:35 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 17 Feb 2013 06:12:35 -0500 (EST) Subject: Direct Host Address In-Reply-To: <20130217104402.GG23843@redhat.com> Message-ID: <1437433971.1365545.1361099555481.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Muli Salem" , arch at ovirt.org > Sent: Sunday, February 17, 2013 12:44:02 PM > Subject: Re: Direct Host Address > > On Thu, Feb 14, 2013 at 03:27:57PM -0500, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > > From: "Muli Salem" > > > To: "Mike Kolesnik" > > > Cc: arch at ovirt.org > > > Sent: Sunday, February 10, 2013 6:09:30 PM > > > Subject: Re: Direct Host Address > > > > > > > > "Current behaviour assumes the network interface with the > > > > specified > > > > address is configured properly in the engine although this may > > > > not > > > > be the case initially" > > > > > > > > I don't understand what does this mean, which interface are you > > > > referring to and what does it have to do with being configured > > > > in > > > > the engine? > > > > The next line is also unclear to me: > > > > "The direct address allows the engine to connect to the host, > > > > without > > > > knowing the exact configuration of the network interface that > > > > has > > > > the address. " > > > > > > > > > > Regarding the last two sentences you quoted: > > > > > > I am referring to the interface that has the IP that the user > > > gives > > > us (with regards to current behavior). > > > At the moment, we assume that the given IP is for an interface > > > that > > > can communicate with the engine (when in practice, this may not > > > be > > > the case). > > > So separating the two addresses, allows us to ask the admin for > > > an > > > alternate IP address that will allow communication without > > > needing > > > to know the specific configuration (for example, whether this is > > > a > > > VLAN network or not). > > > > > > Perhaps the wording should be changed a bit to clarify. > > > > I still don't get it... can you please provide real world use case? > > > > When can we access the alternate address and not the management > > address? > > We have customers who want to install vdsm via native connection, but > manage it over a VLAN. If you want to add a fresh host, you cannot > use > its management address (that sits inside the vlan). > So as far as I understand the prerequisite of this feature is to perform host deploy (ovirt-host-deploy) without constructing the management bridge. In this mode, during host deployment (ovirt-host-deploy) the engine uses the host name only to be able to construct proper CN field for the certificate of VDSM. Then the engine performs provisioning of the host to define the host name's ip address on the optional vlan id that is shared by the entire cluster. Maybe there will not be a management bridge at all, which makes me happy! This means that: 1. No management bridge name is to be provided to ovirt-host-deply (this is to do in the prerequisite of the feature). 2. New parameter for the VdsDeploy at engine side of IP address to SSH. 3. After VdsDeploy is finished, there is provisioning to define the management address on the host using standard VDSM communication. Am I missing anything? Regards, Alon From alonbl at redhat.com Sun Feb 17 20:57:33 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 17 Feb 2013 15:57:33 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <999203743.6904373.1360277663937.JavaMail.root@redhat.com> Message-ID: <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. For the open questions: 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. 3. I think that if we can avoid aliases it would be nice. 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management network setup from vdsm configuration instead of persisting it to the distribution width configuration. Regards, Alon Bar-Lev ----- Original Message ----- > From: "Antoni Segura Puimedon" > To: arch at ovirt.org, vdsm-devel at fedorahosted.org > Sent: Friday, February 8, 2013 12:54:23 AM > Subject: vdsm networking changes proposal > > Hi fellow oVirters! > > The network team and a few others have toyed in the past with several > important > changes like using open vSwitch, talking D-BUS to NM, making the > network > non-persistent, etc. > > It is with some of this changes in mind that we (special thanks go to > Livnat > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for > a new architecture for vdsm's networking part. This proposal is > intended to > make our software more adaptable to new components and use cases, > eliminate > distro dependancies as much as possible and improve the > responsiveness and > scalability of the networking operations. > > To do so, it proposes an object oriented representation of the > different > elements that come into play in our networking use cases. > > But enough of introduction, please go to the feature page that we > have put > together and help us with your feedback, questions proposals and > extensions. > > http://www.ovirt.org/Feature/NetworkReloaded > > > Best regards, > > Toni > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From kmayilsa at redhat.com Mon Feb 18 03:09:45 2013 From: kmayilsa at redhat.com (Kanagaraj Mayilsamy) Date: Sun, 17 Feb 2013 22:09:45 -0500 (EST) Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com> Message-ID: <100470733.1912624.1361156985822.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Daniel Erez" > Cc: arch at ovirt.org, engine-devel at ovirt.org > Sent: Saturday, February 16, 2013 1:07:56 AM > Subject: Re: [Engine-devel] REST API calls from the GUI > > Hi Daniel, > > > The first alternative can be implemented by using GWT > > RequestBuilder (for sending the HTTP requests) > > and GWT overlay types (that can be generated from java POJOs). > > Probably best performance-wise/less data type conversions/etc; > > However, basically means writing a JavaScript SDK. > > Yes, we can use RequestBuilder for making AJAX HTTP requests, but > using GWT overlay types is possible only if REST API fully supports > JSON format. In case of XML format, we would have to use GWT > XMLParser to map "restapi-types" entities/collections to/from XML > strings, e.g. we could write GWT deferred binding generators to > generate such mappers from current schema. AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically. > > > The benefit of the second alternative is currently rather vague > > since the Java SDK can't be converted to JavaScript as is > > (can't use apache.commons and javax packages in GWT client side). > > Need to check how easily they can be replaced > > with JRE libraries that GWT can emulate (for supporting both GWT > > web and debug mode). > > Indeed, we can't use Java REST API SDK as it is with GWT: > https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation > > This means we need to implement our own transport layer > (RequestBuilder) and most likely also the marshalling layer > (XMLParser vs. JSONParser vs. overlay types). It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK. > > > A third alternative could be simply maintaining the current GWT RPC > > mechanism we use. > > I.e. integrating the Java SDK into the GWT servlet, which means > > wrapping the API into GenericApiGWTService. > > The main drawback is an additional layer of data type conversion > > and round-trip: > > Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > > This is interesting, generic API could be used to transfer > "restapi-types", along with extra information to emulate proper HTTP > request, without any marshalling involved. > We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. > Vojtech > > > ----- Original Message ----- > From: "Daniel Erez" > To: "Michael Pasternak" > Cc: engine-devel at ovirt.org, "Einav Cohen" , > arch at ovirt.org, "Libor Spevak" , "Vojtech Szocs" > > Sent: Friday, February 15, 2013 7:17:43 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > > > ----- Original Message ----- > > From: "Michael Pasternak" > > To: "Libor Spevak" > > Cc: engine-devel at ovirt.org, "Daniel Erez" , > > "Gilad Chaplik" , "Einav Cohen" > > , arch at ovirt.org > > Sent: Wednesday, February 13, 2013 12:55:36 PM > > Subject: Re: [Engine-devel] REST API calls from the GUI > > > > > > Hi Libor, > > > > This issue came across in one of the conversations i had with UX > > folks, but since we didn't end > > up with any conclusion/road map (nor discussed it properly to hear > > other thoughts), this is a perfect > > place to start this discussion, > > > > Intuitively REST is a way to go with GWT AJAX calls > > --------------------------------------------------- > > > > pros > > ==== > > > > - api data objects can be reused by generating java classes (using > > jaxb) from the rest schema [1] > > - no backend logic will be duplicated as api abstracts the backend > > exposing RESTful collection/resources to operate on > > - development against api is "easy" as api describes itself in RSDL > > [2] > > > > cons > > ==== > > > > - implementing transport layer (HTTP) under GWT > > - implementing own j2xml/json/yaml/... marshalling layer > > - implementing own error handling mechanism > > - implementing REST callback mechanism (in GWT) > > - constant maintenance of the data objects generated from the api > > - painful for Java developers > > > > Java-SDK > > -------- > > > > pros > > ==== > > > > - abstracts transport layer (leaving developer in standard Java > > api) > > - typesafe code (no need to mess with XML bulks) > > - has own data objects to work with > > - abstracts authentication/authorization > > (kerberos/cookie/session/etc.) > > - since SDK is auto-generated, it can be easily extended with > > required > > features to support UI (such as callback infrastructure for > > instance) > > > > cons > > ==== > > > > - has to be converted in to Javascript (not sure what the impacts > > are > > in terms of AJAX calls/etc.) > > - probably much more cons that we're not aware of and will have to > > figure out with POC > > > > > > thoughts? > > > The first alternative can be implemented by using GWT RequestBuilder > (for sending the HTTP requests) > and GWT overlay types (that can be generated from java POJOs). > Probably best performance-wise/less data type conversions/etc; > However, basically means writing a JavaScript SDK. > > The benefit of the second alternative is currently rather vague since > the Java SDK can't be converted to JavaScript as is > (can't use apache.commons and javax packages in GWT client side). > Need to check how easily they can be replaced > with JRE libraries that GWT can emulate (for supporting both GWT web > and debug mode). > > A third alternative could be simply maintaining the current GWT RPC > mechanism we use. > I.e. integrating the Java SDK into the GWT servlet, which means > wrapping the API into GenericApiGWTService. > The main drawback is an additional layer of data type conversion and > round-trip: > Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > > > > > > [1] http[s]://server[:port]/api?schema > > [2] http[s]://server[:port]/api?rsdl > > > > On 02/12/2013 06:13 PM, Libor Spevak wrote: > > > Hi, > > > > > > I would like to ask, if there have been discussions about an > > > option > > > to call REST API services directly from the Frontend (GWT layer)? > > > GWT compiles Java frontend-side to > > > Javascript, calls to backend services are performed > > > "transparently" > > > by the framework using AJAX support. But, there is still a need > > > to > > > have a special set of data objects > > > and the server-side logic can duplicate. > > > > > > Java REST API SDK enables to build "thick" client. The calls are > > > realized using e.g. Apache HttClient and supported libraries. I > > > think the requirements of GWT can be a > > > little bit different, but something overlaps. > > > > > > I found several links about REST API support from GWT, so there > > > is > > > something for inspiration... > > > > > > - http://www.spiffyui.org/ > > > - http://www.zackgrossbart.com/hackito/gwt-rest/ > > > - http://code.google.com/p/gwt-rest/ > > > - http://restygwt.fusesource.org/ > > > > > > But, do you think it would be useful and what drawbacks can occur > > > (authentication, authorization, response times, need to support > > > larger set of services, painful > > > refactoring, ...)? > > > > > > Regards, > > > Libor > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > -- > > > > Michael Pasternak > > RedHat, ENG-Virtualization R&D > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Wed Feb 20 12:25:50 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 20 Feb 2013 14:25:50 +0200 Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <100470733.1912624.1361156985822.JavaMail.root@redhat.com> References: <100470733.1912624.1361156985822.JavaMail.root@redhat.com> Message-ID: <5124C0CE.40105@redhat.com> On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: > > > ----- Original Message ----- >> From: "Vojtech Szocs" >> To: "Daniel Erez" >> Cc: arch at ovirt.org, engine-devel at ovirt.org >> Sent: Saturday, February 16, 2013 1:07:56 AM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> Hi Daniel, >> >>> The first alternative can be implemented by using GWT >>> RequestBuilder (for sending the HTTP requests) >>> and GWT overlay types (that can be generated from java POJOs). >>> Probably best performance-wise/less data type conversions/etc; >>> However, basically means writing a JavaScript SDK. >> >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but >> using GWT overlay types is possible only if REST API fully supports >> JSON format. In case of XML format, we would have to use GWT >> XMLParser to map "restapi-types" entities/collections to/from XML >> strings, e.g. we could write GWT deferred binding generators to >> generate such mappers from current schema. > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically. > >> >>> The benefit of the second alternative is currently rather vague >>> since the Java SDK can't be converted to JavaScript as is >>> (can't use apache.commons and javax packages in GWT client side). >>> Need to check how easily they can be replaced >>> with JRE libraries that GWT can emulate (for supporting both GWT >>> web and debug mode). >> >> Indeed, we can't use Java REST API SDK as it is with GWT: >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation >> >> This means we need to implement our own transport layer >> (RequestBuilder) and most likely also the marshalling layer >> (XMLParser vs. JSONParser vs. overlay types). > > It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK. > >> >>> A third alternative could be simply maintaining the current GWT RPC >>> mechanism we use. >>> I.e. integrating the Java SDK into the GWT servlet, which means >>> wrapping the API into GenericApiGWTService. >>> The main drawback is an additional layer of data type conversion >>> and round-trip: >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). >> >> This is interesting, generic API could be used to transfer >> "restapi-types", along with extra information to emulate proper HTTP >> request, without any marshalling involved. >> > > We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization & talking with api. > >> Vojtech >> >> >> ----- Original Message ----- >> From: "Daniel Erez" >> To: "Michael Pasternak" >> Cc: engine-devel at ovirt.org, "Einav Cohen" , >> arch at ovirt.org, "Libor Spevak" , "Vojtech Szocs" >> >> Sent: Friday, February 15, 2013 7:17:43 PM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> >> >> ----- Original Message ----- >>> From: "Michael Pasternak" >>> To: "Libor Spevak" >>> Cc: engine-devel at ovirt.org, "Daniel Erez" , >>> "Gilad Chaplik" , "Einav Cohen" >>> , arch at ovirt.org >>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>> Subject: Re: [Engine-devel] REST API calls from the GUI >>> >>> >>> Hi Libor, >>> >>> This issue came across in one of the conversations i had with UX >>> folks, but since we didn't end >>> up with any conclusion/road map (nor discussed it properly to hear >>> other thoughts), this is a perfect >>> place to start this discussion, >>> >>> Intuitively REST is a way to go with GWT AJAX calls >>> --------------------------------------------------- >>> >>> pros >>> ==== >>> >>> - api data objects can be reused by generating java classes (using >>> jaxb) from the rest schema [1] >>> - no backend logic will be duplicated as api abstracts the backend >>> exposing RESTful collection/resources to operate on >>> - development against api is "easy" as api describes itself in RSDL >>> [2] >>> >>> cons >>> ==== >>> >>> - implementing transport layer (HTTP) under GWT >>> - implementing own j2xml/json/yaml/... marshalling layer >>> - implementing own error handling mechanism >>> - implementing REST callback mechanism (in GWT) >>> - constant maintenance of the data objects generated from the api >>> - painful for Java developers >>> >>> Java-SDK >>> -------- >>> >>> pros >>> ==== >>> >>> - abstracts transport layer (leaving developer in standard Java >>> api) >>> - typesafe code (no need to mess with XML bulks) >>> - has own data objects to work with >>> - abstracts authentication/authorization >>> (kerberos/cookie/session/etc.) >>> - since SDK is auto-generated, it can be easily extended with >>> required >>> features to support UI (such as callback infrastructure for >>> instance) >>> >>> cons >>> ==== >>> >>> - has to be converted in to Javascript (not sure what the impacts >>> are >>> in terms of AJAX calls/etc.) >>> - probably much more cons that we're not aware of and will have to >>> figure out with POC >>> >>> >>> thoughts? >> >> >> The first alternative can be implemented by using GWT RequestBuilder >> (for sending the HTTP requests) >> and GWT overlay types (that can be generated from java POJOs). >> Probably best performance-wise/less data type conversions/etc; >> However, basically means writing a JavaScript SDK. >> >> The benefit of the second alternative is currently rather vague since >> the Java SDK can't be converted to JavaScript as is >> (can't use apache.commons and javax packages in GWT client side). >> Need to check how easily they can be replaced >> with JRE libraries that GWT can emulate (for supporting both GWT web >> and debug mode). >> >> A third alternative could be simply maintaining the current GWT RPC >> mechanism we use. >> I.e. integrating the Java SDK into the GWT servlet, which means >> wrapping the API into GenericApiGWTService. >> The main drawback is an additional layer of data type conversion and >> round-trip: >> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). >> >> >>> >>> [1] http[s]://server[:port]/api?schema >>> [2] http[s]://server[:port]/api?rsdl >>> >>> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>>> Hi, >>>> >>>> I would like to ask, if there have been discussions about an >>>> option >>>> to call REST API services directly from the Frontend (GWT layer)? >>>> GWT compiles Java frontend-side to >>>> Javascript, calls to backend services are performed >>>> "transparently" >>>> by the framework using AJAX support. But, there is still a need >>>> to >>>> have a special set of data objects >>>> and the server-side logic can duplicate. >>>> >>>> Java REST API SDK enables to build "thick" client. The calls are >>>> realized using e.g. Apache HttClient and supported libraries. I >>>> think the requirements of GWT can be a >>>> little bit different, but something overlaps. >>>> >>>> I found several links about REST API support from GWT, so there >>>> is >>>> something for inspiration... >>>> >>>> - http://www.spiffyui.org/ >>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>>> - http://code.google.com/p/gwt-rest/ >>>> - http://restygwt.fusesource.org/ >>>> >>>> But, do you think it would be useful and what drawbacks can occur >>>> (authentication, authorization, response times, need to support >>>> larger set of services, painful >>>> refactoring, ...)? >>>> >>>> Regards, >>>> Libor >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From kmayilsa at redhat.com Wed Feb 20 12:45:02 2013 From: kmayilsa at redhat.com (Kanagaraj Mayilsamy) Date: Wed, 20 Feb 2013 07:45:02 -0500 (EST) Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <5124C0CE.40105@redhat.com> Message-ID: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Kanagaraj Mayilsamy" > Cc: "Vojtech Szocs" , engine-devel at ovirt.org, arch at ovirt.org > Sent: Wednesday, February 20, 2013 5:55:50 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: > > > > > > ----- Original Message ----- > >> From: "Vojtech Szocs" > >> To: "Daniel Erez" > >> Cc: arch at ovirt.org, engine-devel at ovirt.org > >> Sent: Saturday, February 16, 2013 1:07:56 AM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> Hi Daniel, > >> > >>> The first alternative can be implemented by using GWT > >>> RequestBuilder (for sending the HTTP requests) > >>> and GWT overlay types (that can be generated from java POJOs). > >>> Probably best performance-wise/less data type conversions/etc; > >>> However, basically means writing a JavaScript SDK. > >> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but > >> using GWT overlay types is possible only if REST API fully > >> supports > >> JSON format. In case of XML format, we would have to use GWT > >> XMLParser to map "restapi-types" entities/collections to/from XML > >> strings, e.g. we could write GWT deferred binding generators to > >> generate such mappers from current schema. > > > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) > > could be useful instead of generating/writing overlay types. > > AutoBeans will be converted overlay types internally by GWT > > automatically. > > > >> > >>> The benefit of the second alternative is currently rather vague > >>> since the Java SDK can't be converted to JavaScript as is > >>> (can't use apache.commons and javax packages in GWT client side). > >>> Need to check how easily they can be replaced > >>> with JRE libraries that GWT can emulate (for supporting both GWT > >>> web and debug mode). > >> > >> Indeed, we can't use Java REST API SDK as it is with GWT: > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation > >> > >> This means we need to implement our own transport layer > >> (RequestBuilder) and most likely also the marshalling layer > >> (XMLParser vs. JSONParser vs. overlay types). > > > > It would be better if We can come up with a "GWT REST API SDK", > > which is analogous Java SDK. > > > >> > >>> A third alternative could be simply maintaining the current GWT > >>> RPC > >>> mechanism we use. > >>> I.e. integrating the Java SDK into the GWT servlet, which means > >>> wrapping the API into GenericApiGWTService. > >>> The main drawback is an additional layer of data type conversion > >>> and round-trip: > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > >> > >> This is interesting, generic API could be used to transfer > >> "restapi-types", along with extra information to emulate proper > >> HTTP > >> request, without any marshalling involved. > >> > > > > We can't directly use the restapi models in the client side, as > > they have lot of xml and annotations stuff involved which will not > > be compatible with GWT. > > why? they only have jaxb annotations which are 'must' for > serialization & talking with api. > We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. > > > >> Vojtech > >> > >> > >> ----- Original Message ----- > >> From: "Daniel Erez" > >> To: "Michael Pasternak" > >> Cc: engine-devel at ovirt.org, "Einav Cohen" , > >> arch at ovirt.org, "Libor Spevak" , "Vojtech > >> Szocs" > >> > >> Sent: Friday, February 15, 2013 7:17:43 PM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Michael Pasternak" > >>> To: "Libor Spevak" > >>> Cc: engine-devel at ovirt.org, "Daniel Erez" , > >>> "Gilad Chaplik" , "Einav Cohen" > >>> , arch at ovirt.org > >>> Sent: Wednesday, February 13, 2013 12:55:36 PM > >>> Subject: Re: [Engine-devel] REST API calls from the GUI > >>> > >>> > >>> Hi Libor, > >>> > >>> This issue came across in one of the conversations i had with UX > >>> folks, but since we didn't end > >>> up with any conclusion/road map (nor discussed it properly to > >>> hear > >>> other thoughts), this is a perfect > >>> place to start this discussion, > >>> > >>> Intuitively REST is a way to go with GWT AJAX calls > >>> --------------------------------------------------- > >>> > >>> pros > >>> ==== > >>> > >>> - api data objects can be reused by generating java classes > >>> (using > >>> jaxb) from the rest schema [1] > >>> - no backend logic will be duplicated as api abstracts the > >>> backend > >>> exposing RESTful collection/resources to operate on > >>> - development against api is "easy" as api describes itself in > >>> RSDL > >>> [2] > >>> > >>> cons > >>> ==== > >>> > >>> - implementing transport layer (HTTP) under GWT > >>> - implementing own j2xml/json/yaml/... marshalling layer > >>> - implementing own error handling mechanism > >>> - implementing REST callback mechanism (in GWT) > >>> - constant maintenance of the data objects generated from the api > >>> - painful for Java developers > >>> > >>> Java-SDK > >>> -------- > >>> > >>> pros > >>> ==== > >>> > >>> - abstracts transport layer (leaving developer in standard Java > >>> api) > >>> - typesafe code (no need to mess with XML bulks) > >>> - has own data objects to work with > >>> - abstracts authentication/authorization > >>> (kerberos/cookie/session/etc.) > >>> - since SDK is auto-generated, it can be easily extended with > >>> required > >>> features to support UI (such as callback infrastructure for > >>> instance) > >>> > >>> cons > >>> ==== > >>> > >>> - has to be converted in to Javascript (not sure what the impacts > >>> are > >>> in terms of AJAX calls/etc.) > >>> - probably much more cons that we're not aware of and will have > >>> to > >>> figure out with POC > >>> > >>> > >>> thoughts? > >> > >> > >> The first alternative can be implemented by using GWT > >> RequestBuilder > >> (for sending the HTTP requests) > >> and GWT overlay types (that can be generated from java POJOs). > >> Probably best performance-wise/less data type conversions/etc; > >> However, basically means writing a JavaScript SDK. > >> > >> The benefit of the second alternative is currently rather vague > >> since > >> the Java SDK can't be converted to JavaScript as is > >> (can't use apache.commons and javax packages in GWT client side). > >> Need to check how easily they can be replaced > >> with JRE libraries that GWT can emulate (for supporting both GWT > >> web > >> and debug mode). > >> > >> A third alternative could be simply maintaining the current GWT > >> RPC > >> mechanism we use. > >> I.e. integrating the Java SDK into the GWT servlet, which means > >> wrapping the API into GenericApiGWTService. > >> The main drawback is an additional layer of data type conversion > >> and > >> round-trip: > >> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > >> > >> > >>> > >>> [1] http[s]://server[:port]/api?schema > >>> [2] http[s]://server[:port]/api?rsdl > >>> > >>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > >>>> Hi, > >>>> > >>>> I would like to ask, if there have been discussions about an > >>>> option > >>>> to call REST API services directly from the Frontend (GWT > >>>> layer)? > >>>> GWT compiles Java frontend-side to > >>>> Javascript, calls to backend services are performed > >>>> "transparently" > >>>> by the framework using AJAX support. But, there is still a need > >>>> to > >>>> have a special set of data objects > >>>> and the server-side logic can duplicate. > >>>> > >>>> Java REST API SDK enables to build "thick" client. The calls are > >>>> realized using e.g. Apache HttClient and supported libraries. I > >>>> think the requirements of GWT can be a > >>>> little bit different, but something overlaps. > >>>> > >>>> I found several links about REST API support from GWT, so there > >>>> is > >>>> something for inspiration... > >>>> > >>>> - http://www.spiffyui.org/ > >>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > >>>> - http://code.google.com/p/gwt-rest/ > >>>> - http://restygwt.fusesource.org/ > >>>> > >>>> But, do you think it would be useful and what drawbacks can > >>>> occur > >>>> (authentication, authorization, response times, need to support > >>>> larger set of services, painful > >>>> refactoring, ...)? > >>>> > >>>> Regards, > >>>> Libor > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> > >>> -- > >>> > >>> Michael Pasternak > >>> RedHat, ENG-Virtualization R&D > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From mpastern at redhat.com Wed Feb 20 12:56:59 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 20 Feb 2013 14:56:59 +0200 Subject: REST API calls from In-Reply-To: <82414620.2634605.1360833600485.JavaMail.root@redhat.com> References: <82414620.2634605.1360833600485.JavaMail.root@redhat.com> Message-ID: <5124C81B.4080201@redhat.com> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Libor Spevak" >> Cc: engine-devel at ovirt.org, arch at ovirt.org >> Sent: Wednesday, February 13, 2013 12:55:36 PM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> >> Hi Libor, >> >> This issue came across in one of the conversations i had with UX >> folks, but since we didn't end >> up with any conclusion/road map (nor discussed it properly to hear >> other thoughts), this is a perfect >> place to start this discussion, >> >> Intuitively REST is a way to go with GWT AJAX calls >> --------------------------------------------------- >> >> pros >> ==== >> >> - api data objects can be reused by generating java classes (using >> jaxb) from the rest schema [1] >> - no backend logic will be duplicated as api abstracts the backend >> exposing RESTful collection/resources to operate on >> - development against api is "easy" as api describes itself in RSDL >> [2] >> >> cons >> ==== >> >> - implementing transport layer (HTTP) under GWT >> - implementing own j2xml/json/yaml/... marshalling layer >> - implementing own error handling mechanism >> - implementing REST callback mechanism (in GWT) >> - constant maintenance of the data objects generated from the api >> - painful for Java developers >> >> Java-SDK >> -------- >> >> pros >> ==== >> >> - abstracts transport layer (leaving developer in standard Java api) >> - typesafe code (no need to mess with XML bulks) >> - has own data objects to work with >> - abstracts authentication/authorization >> (kerberos/cookie/session/etc.) >> - since SDK is auto-generated, it can be easily extended with >> required >> features to support UI (such as callback infrastructure for >> instance) >> >> cons >> ==== >> >> - has to be converted in to Javascript (not sure what the impacts are >> in terms of AJAX calls/etc.) >> - probably much more cons that we're not aware of and will have to >> figure out with POC >> >> >> thoughts? >> >> [1] http[s]://server[:port]/api?schema >> [2] http[s]://server[:port]/api?rsdl >> > > Although started as a UI request, there are other needs who wish > to use API calls with a different transport. For example a backend > hook which gets a REST entry point it can use to fetch for additional > data, or perform actions. In this case I'd expect an internal connection > rather than creating additional connections. > How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. > >> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>> Hi, >>> >>> I would like to ask, if there have been discussions about an option >>> to call REST API services directly from the Frontend (GWT layer)? >>> GWT compiles Java frontend-side to >>> Javascript, calls to backend services are performed "transparently" >>> by the framework using AJAX support. But, there is still a need to >>> have a special set of data objects >>> and the server-side logic can duplicate. >>> >>> Java REST API SDK enables to build "thick" client. The calls are >>> realized using e.g. Apache HttClient and supported libraries. I >>> think the requirements of GWT can be a >>> little bit different, but something overlaps. >>> >>> I found several links about REST API support from GWT, so there is >>> something for inspiration... >>> >>> - http://www.spiffyui.org/ >>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>> - http://code.google.com/p/gwt-rest/ >>> - http://restygwt.fusesource.org/ >>> >>> But, do you think it would be useful and what drawbacks can occur >>> (authentication, authorization, response times, need to support >>> larger set of services, painful >>> refactoring, ...)? >>> >>> Regards, >>> Libor >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed Feb 20 13:07:15 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 20 Feb 2013 15:07:15 +0200 Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com> References: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com> Message-ID: <5124CA83.1040600@redhat.com> On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote: > > ----- Original Message ----- >> > From: "Michael Pasternak" >> > To: "Kanagaraj Mayilsamy" >> > Cc: "Vojtech Szocs" , engine-devel at ovirt.org, arch at ovirt.org >> > Sent: Wednesday, February 20, 2013 5:55:50 PM >> > Subject: Re: [Engine-devel] REST API calls from the GUI >> > >> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: >>> > > >>> > > >>> > > ----- Original Message ----- >>>> > >> From: "Vojtech Szocs" >>>> > >> To: "Daniel Erez" >>>> > >> Cc: arch at ovirt.org, engine-devel at ovirt.org >>>> > >> Sent: Saturday, February 16, 2013 1:07:56 AM >>>> > >> Subject: Re: [Engine-devel] REST API calls from the GUI >>>> > >> >>>> > >> Hi Daniel, >>>> > >> >>>>> > >>> The first alternative can be implemented by using GWT >>>>> > >>> RequestBuilder (for sending the HTTP requests) >>>>> > >>> and GWT overlay types (that can be generated from java POJOs). >>>>> > >>> Probably best performance-wise/less data type conversions/etc; >>>>> > >>> However, basically means writing a JavaScript SDK. >>>> > >> >>>> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but >>>> > >> using GWT overlay types is possible only if REST API fully >>>> > >> supports >>>> > >> JSON format. In case of XML format, we would have to use GWT >>>> > >> XMLParser to map "restapi-types" entities/collections to/from XML >>>> > >> strings, e.g. we could write GWT deferred binding generators to >>>> > >> generate such mappers from current schema. >>> > > >>> > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) >>> > > could be useful instead of generating/writing overlay types. >>> > > AutoBeans will be converted overlay types internally by GWT >>> > > automatically. >>> > > >>>> > >> >>>>> > >>> The benefit of the second alternative is currently rather vague >>>>> > >>> since the Java SDK can't be converted to JavaScript as is >>>>> > >>> (can't use apache.commons and javax packages in GWT client side). >>>>> > >>> Need to check how easily they can be replaced >>>>> > >>> with JRE libraries that GWT can emulate (for supporting both GWT >>>>> > >>> web and debug mode). >>>> > >> >>>> > >> Indeed, we can't use Java REST API SDK as it is with GWT: >>>> > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation >>>> > >> >>>> > >> This means we need to implement our own transport layer >>>> > >> (RequestBuilder) and most likely also the marshalling layer >>>> > >> (XMLParser vs. JSONParser vs. overlay types). >>> > > >>> > > It would be better if We can come up with a "GWT REST API SDK", >>> > > which is analogous Java SDK. >>> > > >>>> > >> >>>>> > >>> A third alternative could be simply maintaining the current GWT >>>>> > >>> RPC >>>>> > >>> mechanism we use. >>>>> > >>> I.e. integrating the Java SDK into the GWT servlet, which means >>>>> > >>> wrapping the API into GenericApiGWTService. >>>>> > >>> The main drawback is an additional layer of data type conversion >>>>> > >>> and round-trip: >>>>> > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). >>>> > >> >>>> > >> This is interesting, generic API could be used to transfer >>>> > >> "restapi-types", along with extra information to emulate proper >>>> > >> HTTP >>>> > >> request, without any marshalling involved. >>>> > >> >>> > > >>> > > We can't directly use the restapi models in the client side, as >>> > > they have lot of xml and annotations stuff involved which will not >>> > > be compatible with GWT. >> > >> > why? they only have jaxb annotations which are 'must' for >> > serialization & talking with api. >> > > We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation > > If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), if your schema->java converting tool support this, you're okay. -- Michael Pasternak RedHat, ENG-Virtualization R&D From rydekull at gmail.com Wed Feb 20 19:09:15 2013 From: rydekull at gmail.com (Alexander Rydekull) Date: Wed, 20 Feb 2013 20:09:15 +0100 Subject: Unplanned Outage :: www.oVirt.org (Web) :: 2013-02-20 11:00 CET Message-ID: There was an (unplanned) outage of www.oVirt.org (Web) for roughly 5 hours, atleast. I dont know exactly when it started. == Details == The reason for the outage was some faults in the Openshift setup, not on our part but Openshift themselves. When another customer of their services got a heavy load under specific conditions it actually rendered "nearby" customers unable to function at all. == Affected services == * Any service using www.ovirt.org == Future plans == It is unfortunate that it happens, all we can do in a case like this is to try and learn how to detect these errors automatically and if they arise notify the openshift people immediately. In additon to above notes, thank you everyone that reported it to us. It helps us to know that something is wrong when you communicate it, well done! -- /Alexander Rydekull -------------- next part -------------- An HTML attachment was scrubbed... URL: From wudxw at linux.vnet.ibm.com Thu Feb 21 08:46:16 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Thu, 21 Feb 2013 16:46:16 +0800 Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <1361179401.13448.54.camel@dhcp-29-7.brq.redhat.com> References: <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> <1361179401.13448.54.camel@dhcp-29-7.brq.redhat.com> Message-ID: <5125DED8.9050706@linux.vnet.ibm.com> On 02/18/2013 05:23 PM, David Ja?a wrote: > Hi, > > Alon Bar-Lev p??e v Ne 17. 02. 2013 v 15:57 -0500: >> Hello Antoni, >> >> Great work! >> I am very excited we are going this route, it is first of many to allow us to be run on different distributions. >> I apologize I got to this so late. >> >> Notes for the model, I am unsure if someone already noted. >> >> I think that the abstraction should be more than entity and properties. >> >> For example: >> >> nic is a network interface >> bridge is a network interface and ports network interfaces >> bound is a network interface and slave network interfaces >> vlan is a network interface and vlan id >> >> network interface can have: >> - name >> - ip config >> - state >> - mtu >> >> this way it would be easier to share common code that handle pure interfaces. >> >> I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? > Team is a new implementation of bonding in Linux kernel IIRC. > >> bridge >> - iproute2 provider >> - ovs provider >> - ifcfg provider >> >> bond >> - iproute2 >> - team >> - ovs >> - ifcfg >> >> vlan >> - iproute2 >> - ovs >> - ifcfg >> >> So we can get a configuration of: >> bridge:iproute2 >> bond:team >> vlan:ovs >> >> ? >> >> I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. > Isn't it better to separate the two goals and persuade qemu developers to implement TLS for migration connections? +1 for implementing it in qemu > > David > >> For the open questions: >> >> 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. >> >> 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. >> >> 3. I think that if we can avoid aliases it would be nice. >> >> 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. >> >> I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management network setup from vdsm configuration instead of persisting it to the distribution width configuration. >> >> Regards, >> Alon Bar-Lev >> >> ----- Original Message ----- >>> From: "Antoni Segura Puimedon" >>> To: arch at ovirt.org, vdsm-devel at fedorahosted.org >>> Sent: Friday, February 8, 2013 12:54:23 AM >>> Subject: vdsm networking changes proposal >>> >>> Hi fellow oVirters! >>> >>> The network team and a few others have toyed in the past with several >>> important >>> changes like using open vSwitch, talking D-BUS to NM, making the >>> network >>> non-persistent, etc. >>> >>> It is with some of this changes in mind that we (special thanks go to >>> Livnat >>> Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for >>> a new architecture for vdsm's networking part. This proposal is >>> intended to >>> make our software more adaptable to new components and use cases, >>> eliminate >>> distro dependancies as much as possible and improve the >>> responsiveness and >>> scalability of the networking operations. >>> >>> To do so, it proposes an object oriented representation of the >>> different >>> elements that come into play in our networking use cases. >>> >>> But enough of introduction, please go to the feature page that we >>> have put >>> together and help us with your feedback, questions proposals and >>> extensions. >>> >>> http://www.ovirt.org/Feature/NetworkReloaded >>> >>> >>> Best regards, >>> >>> Toni >>> _______________________________________________ >>> Arch mailing list >>> Arch at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >>> >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From wudxw at linux.vnet.ibm.com Thu Feb 21 09:55:45 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Thu, 21 Feb 2013 17:55:45 +0800 Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <5125DED8.9050706@linux.vnet.ibm.com> References: <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> <1361179401.13448.54.camel@dhcp-29-7.brq.redhat.com> <5125DED8.9050706@linux.vnet.ibm.com> Message-ID: <5125EF21.1050205@linux.vnet.ibm.com> On Thu 21 Feb 2013 04:46:16 PM CST, Mark Wu wrote: > On 02/18/2013 05:23 PM, David Ja?a wrote: >> Hi, >> >> Alon Bar-Lev p??e v Ne 17. 02. 2013 v 15:57 -0500: >>> Hello Antoni, >>> >>> Great work! >>> I am very excited we are going this route, it is first of many to >>> allow us to be run on different distributions. >>> I apologize I got to this so late. >>> >>> Notes for the model, I am unsure if someone already noted. >>> >>> I think that the abstraction should be more than entity and properties. >>> >>> For example: >>> >>> nic is a network interface >>> bridge is a network interface and ports network interfaces >>> bound is a network interface and slave network interfaces >>> vlan is a network interface and vlan id >>> >>> network interface can have: >>> - name >>> - ip config >>> - state >>> - mtu >>> >>> this way it would be easier to share common code that handle pure >>> interfaces. >>> >>> I don't quite understand the 'Team' configurator, are you suggesting >>> a provider for each technology? >> Team is a new implementation of bonding in Linux kernel IIRC. >> >>> bridge >>> - iproute2 provider >>> - ovs provider >>> - ifcfg provider >>> >>> bond >>> - iproute2 >>> - team >>> - ovs >>> - ifcfg >>> >>> vlan >>> - iproute2 >>> - ovs >>> - ifcfg >>> >>> So we can get a configuration of: >>> bridge:iproute2 >>> bond:team >>> vlan:ovs >>> >>> ? >>> >>> I also would like us to explore a future alternative of the network >>> configuration via crypto vpn directly from qemu to another qemu, the >>> idea is to have a kerberos like key per layer3(or layer2) >>> destination, while communication is encrypted at user space and sent >>> to a flat network. The advantage of this is that we manage logical >>> network and not physical network, while relaying on hardware to find >>> the best route to destination. The question is how and if we can >>> provide this via the suggestion abstraction. But maybe it is too >>> soon to address this kind of future. >> Isn't it better to separate the two goals and persuade qemu >> developers to implement TLS for migration connections? > +1 for implementing it in qemu >> >> David >> >>> For the open questions: >>> >>> 1. Yes, I think that mode should be non-persistence, persistence >>> providers should emulate non-persistence operations by diff between >>> what they have and the goal. >>> >>> 2. Once vdsm is installed, the mode it runs should be fixed. So the >>> only question is what is the selected profile during host deployment. >>> >>> 3. I think that if we can avoid aliases it would be nice. >>> >>> 4. Keeping the least persistence information would be flexible. I >>> would love to see a zero persistence mode available, for example if >>> management interface is dhcp or manually configured. >>> >>> I am very fond of the iproute2 configuration, and don't mind if >>> administrator configures the management interface manually. I think >>> this can supersede the ifcfg quite easily in most cases. In these >>> rare cases administrator use ovirt to modify the network interface >>> we may consider delegating persistence to totally different model. >>> But as far as I understand the problem is solely related to the >>> management connectivity, so we can implement a simple bootstrap of >>> non-persistence module to reconstruct the management network setup >>> from vdsm configuration instead of persisting it to the distribution >>> width configuration. >>> >>> Regards, >>> Alon Bar-Lev >>> >>> ----- Original Message ----- >>>> From: "Antoni Segura Puimedon" >>>> To: arch at ovirt.org, vdsm-devel at fedorahosted.org >>>> Sent: Friday, February 8, 2013 12:54:23 AM >>>> Subject: vdsm networking changes proposal >>>> >>>> Hi fellow oVirters! >>>> >>>> The network team and a few others have toyed in the past with several >>>> important >>>> changes like using open vSwitch, talking D-BUS to NM, making the >>>> network >>>> non-persistent, etc. >>>> >>>> It is with some of this changes in mind that we (special thanks go to >>>> Livnat >>>> Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for >>>> a new architecture for vdsm's networking part. This proposal is >>>> intended to >>>> make our software more adaptable to new components and use cases, >>>> eliminate >>>> distro dependancies as much as possible and improve the >>>> responsiveness and >>>> scalability of the networking operations. >>>> >>>> To do so, it proposes an object oriented representation of the >>>> different >>>> elements that come into play in our networking use cases. >>>> >>>> But enough of introduction, please go to the feature page that we >>>> have put >>>> together and help us with your feedback, questions proposals and >>>> extensions. >>>> >>>> http://www.ovirt.org/Feature/NetworkReloaded >>>> >>>> >>>> Best regards, >>>> >>>> Toni >>>> _______________________________________________ >>>> Arch mailing list >>>> Arch at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/arch >>>> >>> _______________________________________________ >>> vdsm-devel mailing list >>> vdsm-devel at lists.fedorahosted.org >>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel Sorry for coming to it so late. I get the following comments and questions about the proposal. I suggest to add a field of top interface to the network, and only apply IpConfig and mtu to it. For the openvswitch configurator, it needs assistance of iproute2 because it can't configure ip/netmask/gw and mtu. I can't figure out the point to allow different configurators except openvswitch coexist. It could cause unnecessary complexity. In the proposal, the rollback mechanism can be used to persist configuration for iproute2. Why do we still need NetworkManager? I think the solution of "iproute2 + openvswitch + serializing configuration objects" can meet all our requirements. I remember that Dan had a concern of adding a new standard about it in previous discussion. Have we already get agreement on it? Mark From vszocs at redhat.com Thu Feb 21 13:30:20 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 21 Feb 2013 08:30:20 -0500 (EST) Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <5124CA83.1040600@redhat.com> Message-ID: <960012516.4950999.1361453420281.JavaMail.root@redhat.com> Hi guys, >>> > > We can't directly use the restapi models in the client side, as >>> > > they have lot of xml and annotations stuff involved which will not >>> > > be compatible with GWT. >> > >> > why? they only have jaxb annotations which are 'must' for >> > serialization & talking with api. Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript. The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue). Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd). As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML <--> Rest API Java type conversion. > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML > as they are defined in the api schema and not using Java naming convention (as XJC does), Yeah, with XML representation we would have to do this ourselves. On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?) >>> > > It would be better if We can come up with a "GWT REST API SDK", >>> > > which is analogous Java SDK. I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients. Vojtech ----- Original Message ----- From: "Michael Pasternak" To: "Kanagaraj Mayilsamy" Cc: "Vojtech Szocs" , engine-devel at ovirt.org, arch at ovirt.org Sent: Wednesday, February 20, 2013 2:07:15 PM Subject: Re: [Engine-devel] REST API calls from the GUI On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote: > > ----- Original Message ----- >> > From: "Michael Pasternak" >> > To: "Kanagaraj Mayilsamy" >> > Cc: "Vojtech Szocs" , engine-devel at ovirt.org, arch at ovirt.org >> > Sent: Wednesday, February 20, 2013 5:55:50 PM >> > Subject: Re: [Engine-devel] REST API calls from the GUI >> > >> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: >>> > > >>> > > >>> > > ----- Original Message ----- >>>> > >> From: "Vojtech Szocs" >>>> > >> To: "Daniel Erez" >>>> > >> Cc: arch at ovirt.org, engine-devel at ovirt.org >>>> > >> Sent: Saturday, February 16, 2013 1:07:56 AM >>>> > >> Subject: Re: [Engine-devel] REST API calls from the GUI >>>> > >> >>>> > >> Hi Daniel, >>>> > >> >>>>> > >>> The first alternative can be implemented by using GWT >>>>> > >>> RequestBuilder (for sending the HTTP requests) >>>>> > >>> and GWT overlay types (that can be generated from java POJOs). >>>>> > >>> Probably best performance-wise/less data type conversions/etc; >>>>> > >>> However, basically means writing a JavaScript SDK. >>>> > >> >>>> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but >>>> > >> using GWT overlay types is possible only if REST API fully >>>> > >> supports >>>> > >> JSON format. In case of XML format, we would have to use GWT >>>> > >> XMLParser to map "restapi-types" entities/collections to/from XML >>>> > >> strings, e.g. we could write GWT deferred binding generators to >>>> > >> generate such mappers from current schema. >>> > > >>> > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) >>> > > could be useful instead of generating/writing overlay types. >>> > > AutoBeans will be converted overlay types internally by GWT >>> > > automatically. >>> > > >>>> > >> >>>>> > >>> The benefit of the second alternative is currently rather vague >>>>> > >>> since the Java SDK can't be converted to JavaScript as is >>>>> > >>> (can't use apache.commons and javax packages in GWT client side). >>>>> > >>> Need to check how easily they can be replaced >>>>> > >>> with JRE libraries that GWT can emulate (for supporting both GWT >>>>> > >>> web and debug mode). >>>> > >> >>>> > >> Indeed, we can't use Java REST API SDK as it is with GWT: >>>> > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation >>>> > >> >>>> > >> This means we need to implement our own transport layer >>>> > >> (RequestBuilder) and most likely also the marshalling layer >>>> > >> (XMLParser vs. JSONParser vs. overlay types). >>> > > >>> > > It would be better if We can come up with a "GWT REST API SDK", >>> > > which is analogous Java SDK. >>> > > >>>> > >> >>>>> > >>> A third alternative could be simply maintaining the current GWT >>>>> > >>> RPC >>>>> > >>> mechanism we use. >>>>> > >>> I.e. integrating the Java SDK into the GWT servlet, which means >>>>> > >>> wrapping the API into GenericApiGWTService. >>>>> > >>> The main drawback is an additional layer of data type conversion >>>>> > >>> and round-trip: >>>>> > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). >>>> > >> >>>> > >> This is interesting, generic API could be used to transfer >>>> > >> "restapi-types", along with extra information to emulate proper >>>> > >> HTTP >>>> > >> request, without any marshalling involved. >>>> > >> >>> > > >>> > > We can't directly use the restapi models in the client side, as >>> > > they have lot of xml and annotations stuff involved which will not >>> > > be compatible with GWT. >> > >> > why? they only have jaxb annotations which are 'must' for >> > serialization & talking with api. >> > > We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation > > If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), if your schema->java converting tool support this, you're okay. -- Michael Pasternak RedHat, ENG-Virtualization R&D From dfediuck at redhat.com Thu Feb 21 16:54:59 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 21 Feb 2013 11:54:59 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <5124C81B.4080201@redhat.com> Message-ID: <1559481678.7174578.1361465699455.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Doron Fediuck" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Wednesday, February 20, 2013 2:56:59 PM > Subject: Re: [Engine-devel] REST API calls from > > On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > > > ----- Original Message ----- > >> From: "Michael Pasternak" > >> To: "Libor Spevak" > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > >> Sent: Wednesday, February 13, 2013 12:55:36 PM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> > >> Hi Libor, > >> > >> This issue came across in one of the conversations i had with UX > >> folks, but since we didn't end > >> up with any conclusion/road map (nor discussed it properly to hear > >> other thoughts), this is a perfect > >> place to start this discussion, > >> > >> Intuitively REST is a way to go with GWT AJAX calls > >> --------------------------------------------------- > >> > >> pros > >> ==== > >> > >> - api data objects can be reused by generating java classes (using > >> jaxb) from the rest schema [1] > >> - no backend logic will be duplicated as api abstracts the backend > >> exposing RESTful collection/resources to operate on > >> - development against api is "easy" as api describes itself in > >> RSDL > >> [2] > >> > >> cons > >> ==== > >> > >> - implementing transport layer (HTTP) under GWT > >> - implementing own j2xml/json/yaml/... marshalling layer > >> - implementing own error handling mechanism > >> - implementing REST callback mechanism (in GWT) > >> - constant maintenance of the data objects generated from the api > >> - painful for Java developers > >> > >> Java-SDK > >> -------- > >> > >> pros > >> ==== > >> > >> - abstracts transport layer (leaving developer in standard Java > >> api) > >> - typesafe code (no need to mess with XML bulks) > >> - has own data objects to work with > >> - abstracts authentication/authorization > >> (kerberos/cookie/session/etc.) > >> - since SDK is auto-generated, it can be easily extended with > >> required > >> features to support UI (such as callback infrastructure for > >> instance) > >> > >> cons > >> ==== > >> > >> - has to be converted in to Javascript (not sure what the impacts > >> are > >> in terms of AJAX calls/etc.) > >> - probably much more cons that we're not aware of and will have to > >> figure out with POC > >> > >> > >> thoughts? > >> > >> [1] http[s]://server[:port]/api?schema > >> [2] http[s]://server[:port]/api?rsdl > >> > > > > Although started as a UI request, there are other needs who wish > > to use API calls with a different transport. For example a backend > > hook which gets a REST entry point it can use to fetch for > > additional > > data, or perform actions. In this case I'd expect an internal > > connection > > rather than creating additional connections. > > How would you resolve it generically enough in this context? > > Doron, > > I believe your approach a bit different, UX folks seeking for a > convenient > way of communicating with ovirt public api, e.g closing api<->GUI > gap, and > theirs alternatives where native HTTP layer or Java-SDK based > framework, > while what you need is in-process channel to communicate with the > engine itself, > > i understanding your will of using stable api for this (RESTapi), but > not > sure that doing this via JavaSDK is a good way to go simply because > SDK is > designed to operate in a client-space, while what you need is a > server-space > bridge for that. > Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well. > > > >> On 02/12/2013 06:13 PM, Libor Spevak wrote: > >>> Hi, > >>> > >>> I would like to ask, if there have been discussions about an > >>> option > >>> to call REST API services directly from the Frontend (GWT layer)? > >>> GWT compiles Java frontend-side to > >>> Javascript, calls to backend services are performed > >>> "transparently" > >>> by the framework using AJAX support. But, there is still a need > >>> to > >>> have a special set of data objects > >>> and the server-side logic can duplicate. > >>> > >>> Java REST API SDK enables to build "thick" client. The calls are > >>> realized using e.g. Apache HttClient and supported libraries. I > >>> think the requirements of GWT can be a > >>> little bit different, but something overlaps. > >>> > >>> I found several links about REST API support from GWT, so there > >>> is > >>> something for inspiration... > >>> > >>> - http://www.spiffyui.org/ > >>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > >>> - http://code.google.com/p/gwt-rest/ > >>> - http://restygwt.fusesource.org/ > >>> > >>> But, do you think it would be useful and what drawbacks can occur > >>> (authentication, authorization, response times, need to support > >>> larger set of services, painful > >>> refactoring, ...)? > >>> > >>> Regards, > >>> Libor > >>> From ovedo at redhat.com Sun Feb 24 07:05:58 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 24 Feb 2013 02:05:58 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <1559481678.7174578.1361465699455.JavaMail.root@redhat.com> Message-ID: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: "Michael Pasternak" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Thursday, February 21, 2013 6:54:59 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Michael Pasternak" > > To: "Doron Fediuck" > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > Sent: Wednesday, February 20, 2013 2:56:59 PM > > Subject: Re: [Engine-devel] REST API calls from > > > > On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Michael Pasternak" > > >> To: "Libor Spevak" > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > > >> Sent: Wednesday, February 13, 2013 12:55:36 PM > > >> Subject: Re: [Engine-devel] REST API calls from the GUI > > >> > > >> > > >> Hi Libor, > > >> > > >> This issue came across in one of the conversations i had with UX > > >> folks, but since we didn't end > > >> up with any conclusion/road map (nor discussed it properly to > > >> hear > > >> other thoughts), this is a perfect > > >> place to start this discussion, > > >> > > >> Intuitively REST is a way to go with GWT AJAX calls > > >> --------------------------------------------------- > > >> > > >> pros > > >> ==== > > >> > > >> - api data objects can be reused by generating java classes > > >> (using > > >> jaxb) from the rest schema [1] > > >> - no backend logic will be duplicated as api abstracts the > > >> backend > > >> exposing RESTful collection/resources to operate on > > >> - development against api is "easy" as api describes itself in > > >> RSDL > > >> [2] > > >> > > >> cons > > >> ==== > > >> > > >> - implementing transport layer (HTTP) under GWT > > >> - implementing own j2xml/json/yaml/... marshalling layer > > >> - implementing own error handling mechanism > > >> - implementing REST callback mechanism (in GWT) > > >> - constant maintenance of the data objects generated from the > > >> api > > >> - painful for Java developers > > >> > > >> Java-SDK > > >> -------- > > >> > > >> pros > > >> ==== > > >> > > >> - abstracts transport layer (leaving developer in standard Java > > >> api) > > >> - typesafe code (no need to mess with XML bulks) > > >> - has own data objects to work with > > >> - abstracts authentication/authorization > > >> (kerberos/cookie/session/etc.) > > >> - since SDK is auto-generated, it can be easily extended with > > >> required > > >> features to support UI (such as callback infrastructure for > > >> instance) > > >> > > >> cons > > >> ==== > > >> > > >> - has to be converted in to Javascript (not sure what the > > >> impacts > > >> are > > >> in terms of AJAX calls/etc.) > > >> - probably much more cons that we're not aware of and will have > > >> to > > >> figure out with POC > > >> > > >> > > >> thoughts? > > >> > > >> [1] http[s]://server[:port]/api?schema > > >> [2] http[s]://server[:port]/api?rsdl > > >> > > > > > > Although started as a UI request, there are other needs who wish > > > to use API calls with a different transport. For example a > > > backend > > > hook which gets a REST entry point it can use to fetch for > > > additional > > > data, or perform actions. In this case I'd expect an internal > > > connection > > > rather than creating additional connections. > > > How would you resolve it generically enough in this context? > > > > Doron, > > > > I believe your approach a bit different, UX folks seeking for a > > convenient > > way of communicating with ovirt public api, e.g closing api<->GUI > > gap, and > > theirs alternatives where native HTTP layer or Java-SDK based > > framework, > > while what you need is in-process channel to communicate with the > > engine itself, > > > > i understanding your will of using stable api for this (RESTapi), > > but > > not > > sure that doing this via JavaSDK is a good way to go simply because > > SDK is > > designed to operate in a client-space, while what you need is a > > server-space > > bridge for that. > > > > Michael, true but... > Thinking about it differently both UI and hooks needs a client. > The underlying protocols should be abstracted. This is something > which will serve other functions as well. > I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction. I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API. > > > > > >> On 02/12/2013 06:13 PM, Libor Spevak wrote: > > >>> Hi, > > >>> > > >>> I would like to ask, if there have been discussions about an > > >>> option > > >>> to call REST API services directly from the Frontend (GWT > > >>> layer)? > > >>> GWT compiles Java frontend-side to > > >>> Javascript, calls to backend services are performed > > >>> "transparently" > > >>> by the framework using AJAX support. But, there is still a need > > >>> to > > >>> have a special set of data objects > > >>> and the server-side logic can duplicate. > > >>> > > >>> Java REST API SDK enables to build "thick" client. The calls > > >>> are > > >>> realized using e.g. Apache HttClient and supported libraries. I > > >>> think the requirements of GWT can be a > > >>> little bit different, but something overlaps. > > >>> > > >>> I found several links about REST API support from GWT, so there > > >>> is > > >>> something for inspiration... > > >>> > > >>> - http://www.spiffyui.org/ > > >>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > > >>> - http://code.google.com/p/gwt-rest/ > > >>> - http://restygwt.fusesource.org/ > > >>> > > >>> But, do you think it would be useful and what drawbacks can > > >>> occur > > >>> (authentication, authorization, response times, need to support > > >>> larger set of services, painful > > >>> refactoring, ...)? > > >>> > > >>> Regards, > > >>> Libor > > >>> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Sun Feb 24 07:47:28 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 24 Feb 2013 09:47:28 +0200 Subject: [Engine-devel] REST API calls from In-Reply-To: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com> References: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com> Message-ID: <5129C590.6010808@redhat.com> On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Doron Fediuck" >> To: "Michael Pasternak" >> Cc: engine-devel at ovirt.org, arch at ovirt.org >> Sent: Thursday, February 21, 2013 6:54:59 PM >> Subject: Re: [Engine-devel] REST API calls from >> >> >> >> ----- Original Message ----- >>> From: "Michael Pasternak" >>> To: "Doron Fediuck" >>> Cc: engine-devel at ovirt.org, arch at ovirt.org >>> Sent: Wednesday, February 20, 2013 2:56:59 PM >>> Subject: Re: [Engine-devel] REST API calls from >>> >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Michael Pasternak" >>>>> To: "Libor Spevak" >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI >>>>> >>>>> >>>>> Hi Libor, >>>>> >>>>> This issue came across in one of the conversations i had with UX >>>>> folks, but since we didn't end >>>>> up with any conclusion/road map (nor discussed it properly to >>>>> hear >>>>> other thoughts), this is a perfect >>>>> place to start this discussion, >>>>> >>>>> Intuitively REST is a way to go with GWT AJAX calls >>>>> --------------------------------------------------- >>>>> >>>>> pros >>>>> ==== >>>>> >>>>> - api data objects can be reused by generating java classes >>>>> (using >>>>> jaxb) from the rest schema [1] >>>>> - no backend logic will be duplicated as api abstracts the >>>>> backend >>>>> exposing RESTful collection/resources to operate on >>>>> - development against api is "easy" as api describes itself in >>>>> RSDL >>>>> [2] >>>>> >>>>> cons >>>>> ==== >>>>> >>>>> - implementing transport layer (HTTP) under GWT >>>>> - implementing own j2xml/json/yaml/... marshalling layer >>>>> - implementing own error handling mechanism >>>>> - implementing REST callback mechanism (in GWT) >>>>> - constant maintenance of the data objects generated from the >>>>> api >>>>> - painful for Java developers >>>>> >>>>> Java-SDK >>>>> -------- >>>>> >>>>> pros >>>>> ==== >>>>> >>>>> - abstracts transport layer (leaving developer in standard Java >>>>> api) >>>>> - typesafe code (no need to mess with XML bulks) >>>>> - has own data objects to work with >>>>> - abstracts authentication/authorization >>>>> (kerberos/cookie/session/etc.) >>>>> - since SDK is auto-generated, it can be easily extended with >>>>> required >>>>> features to support UI (such as callback infrastructure for >>>>> instance) >>>>> >>>>> cons >>>>> ==== >>>>> >>>>> - has to be converted in to Javascript (not sure what the >>>>> impacts >>>>> are >>>>> in terms of AJAX calls/etc.) >>>>> - probably much more cons that we're not aware of and will have >>>>> to >>>>> figure out with POC >>>>> >>>>> >>>>> thoughts? >>>>> >>>>> [1] http[s]://server[:port]/api?schema >>>>> [2] http[s]://server[:port]/api?rsdl >>>>> >>>> >>>> Although started as a UI request, there are other needs who wish >>>> to use API calls with a different transport. For example a >>>> backend >>>> hook which gets a REST entry point it can use to fetch for >>>> additional >>>> data, or perform actions. In this case I'd expect an internal >>>> connection >>>> rather than creating additional connections. >>>> How would you resolve it generically enough in this context? >>> >>> Doron, >>> >>> I believe your approach a bit different, UX folks seeking for a >>> convenient >>> way of communicating with ovirt public api, e.g closing api<->GUI >>> gap, and >>> theirs alternatives where native HTTP layer or Java-SDK based >>> framework, >>> while what you need is in-process channel to communicate with the >>> engine itself, >>> >>> i understanding your will of using stable api for this (RESTapi), >>> but >>> not >>> sure that doing this via JavaSDK is a good way to go simply because >>> SDK is >>> designed to operate in a client-space, while what you need is a >>> server-space >>> bridge for that. >>> >> >> Michael, true but... >> Thinking about it differently both UI and hooks needs a client. >> The underlying protocols should be abstracted. This is something >> which will serve other functions as well. >> > > I'm not sure we would need a new abstraction here. > Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. +1, that's exactly what i've suggested to begin with. > In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. > I think we should probably do the same for engine plugins, > giving the basic API, and giving a REST session for more advanced operations. > The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, > allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, > without creating a new layer of abstraction. true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are: 1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking RESTeasy by: 2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well 2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse engineering new changes/behaviour of this framework 2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls 2.4 still having round-trip engine->sdk->RESTeasy->engine therefore i think that having own private API in engine for that is a much better solution. > I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API. > > >>>> >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>>>>> Hi, >>>>>> >>>>>> I would like to ask, if there have been discussions about an >>>>>> option >>>>>> to call REST API services directly from the Frontend (GWT >>>>>> layer)? >>>>>> GWT compiles Java frontend-side to >>>>>> Javascript, calls to backend services are performed >>>>>> "transparently" >>>>>> by the framework using AJAX support. But, there is still a need >>>>>> to >>>>>> have a special set of data objects >>>>>> and the server-side logic can duplicate. >>>>>> >>>>>> Java REST API SDK enables to build "thick" client. The calls >>>>>> are >>>>>> realized using e.g. Apache HttClient and supported libraries. I >>>>>> think the requirements of GWT can be a >>>>>> little bit different, but something overlaps. >>>>>> >>>>>> I found several links about REST API support from GWT, so there >>>>>> is >>>>>> something for inspiration... >>>>>> >>>>>> - http://www.spiffyui.org/ >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>>>>> - http://code.google.com/p/gwt-rest/ >>>>>> - http://restygwt.fusesource.org/ >>>>>> >>>>>> But, do you think it would be useful and what drawbacks can >>>>>> occur >>>>>> (authentication, authorization, response times, need to support >>>>>> larger set of services, painful >>>>>> refactoring, ...)? >>>>>> >>>>>> Regards, >>>>>> Libor >>>>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun Feb 24 08:05:13 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 24 Feb 2013 10:05:13 +0200 Subject: [Engine-devel] REST API calls from the GUI In-Reply-To: <960012516.4950999.1361453420281.JavaMail.root@redhat.com> References: <960012516.4950999.1361453420281.JavaMail.root@redhat.com> Message-ID: <5129C9B9.8080707@redhat.com> On 02/21/2013 03:30 PM, Vojtech Szocs wrote: > Hi guys, > >>>>>> >>> > > We can't directly use the restapi models in the client side, as >>>>>> >>> > > they have lot of xml and annotations stuff involved which will not >>>>>> >>> > > be compatible with GWT. >>>> >> > >>>> >> > why? they only have jaxb annotations which are 'must' for >>>> >> > serialization & talking with api. > Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript. > > The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue). > > Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd). > > As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML <--> Rest API Java type conversion. > >> > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML >> > as they are defined in the api schema and not using Java naming convention (as XJC does), > Yeah, with XML representation we would have to do this ourselves. > > On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?) not sure we will support JSON in near future as we're blocked by underlying provider. > >>>>>> >>> > > It would be better if We can come up with a "GWT REST API SDK", >>>>>> >>> > > which is analogous Java SDK. > I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients. > > Vojtech -- Michael Pasternak RedHat, ENG-Virtualization R&D From dfediuck at redhat.com Sun Feb 24 11:20:12 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 24 Feb 2013 06:20:12 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <5129C590.6010808@redhat.com> Message-ID: <1947542298.8405100.1361704812489.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Sunday, February 24, 2013 9:47:28 AM > Subject: Re: [Engine-devel] REST API calls from > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > >> From: "Doron Fediuck" > >> To: "Michael Pasternak" > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > >> Sent: Thursday, February 21, 2013 6:54:59 PM > >> Subject: Re: [Engine-devel] REST API calls from > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Michael Pasternak" > >>> To: "Doron Fediuck" > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > >>> Subject: Re: [Engine-devel] REST API calls from > >>> > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Michael Pasternak" > >>>>> To: "Libor Spevak" > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI > >>>>> > >>>>> > >>>>> Hi Libor, > >>>>> > >>>>> This issue came across in one of the conversations i had with > >>>>> UX > >>>>> folks, but since we didn't end > >>>>> up with any conclusion/road map (nor discussed it properly to > >>>>> hear > >>>>> other thoughts), this is a perfect > >>>>> place to start this discussion, > >>>>> > >>>>> Intuitively REST is a way to go with GWT AJAX calls > >>>>> --------------------------------------------------- > >>>>> > >>>>> pros > >>>>> ==== > >>>>> > >>>>> - api data objects can be reused by generating java classes > >>>>> (using > >>>>> jaxb) from the rest schema [1] > >>>>> - no backend logic will be duplicated as api abstracts the > >>>>> backend > >>>>> exposing RESTful collection/resources to operate on > >>>>> - development against api is "easy" as api describes itself in > >>>>> RSDL > >>>>> [2] > >>>>> > >>>>> cons > >>>>> ==== > >>>>> > >>>>> - implementing transport layer (HTTP) under GWT > >>>>> - implementing own j2xml/json/yaml/... marshalling layer > >>>>> - implementing own error handling mechanism > >>>>> - implementing REST callback mechanism (in GWT) > >>>>> - constant maintenance of the data objects generated from the > >>>>> api > >>>>> - painful for Java developers > >>>>> > >>>>> Java-SDK > >>>>> -------- > >>>>> > >>>>> pros > >>>>> ==== > >>>>> > >>>>> - abstracts transport layer (leaving developer in standard Java > >>>>> api) > >>>>> - typesafe code (no need to mess with XML bulks) > >>>>> - has own data objects to work with > >>>>> - abstracts authentication/authorization > >>>>> (kerberos/cookie/session/etc.) > >>>>> - since SDK is auto-generated, it can be easily extended with > >>>>> required > >>>>> features to support UI (such as callback infrastructure for > >>>>> instance) > >>>>> > >>>>> cons > >>>>> ==== > >>>>> > >>>>> - has to be converted in to Javascript (not sure what the > >>>>> impacts > >>>>> are > >>>>> in terms of AJAX calls/etc.) > >>>>> - probably much more cons that we're not aware of and will have > >>>>> to > >>>>> figure out with POC > >>>>> > >>>>> > >>>>> thoughts? > >>>>> > >>>>> [1] http[s]://server[:port]/api?schema > >>>>> [2] http[s]://server[:port]/api?rsdl > >>>>> > >>>> > >>>> Although started as a UI request, there are other needs who wish > >>>> to use API calls with a different transport. For example a > >>>> backend > >>>> hook which gets a REST entry point it can use to fetch for > >>>> additional > >>>> data, or perform actions. In this case I'd expect an internal > >>>> connection > >>>> rather than creating additional connections. > >>>> How would you resolve it generically enough in this context? > >>> > >>> Doron, > >>> > >>> I believe your approach a bit different, UX folks seeking for a > >>> convenient > >>> way of communicating with ovirt public api, e.g closing api<->GUI > >>> gap, and > >>> theirs alternatives where native HTTP layer or Java-SDK based > >>> framework, > >>> while what you need is in-process channel to communicate with the > >>> engine itself, > >>> > >>> i understanding your will of using stable api for this (RESTapi), > >>> but > >>> not > >>> sure that doing this via JavaSDK is a good way to go simply > >>> because > >>> SDK is > >>> designed to operate in a client-space, while what you need is a > >>> server-space > >>> bridge for that. > >>> > >> > >> Michael, true but... > >> Thinking about it differently both UI and hooks needs a client. > >> The underlying protocols should be abstracted. This is something > >> which will serve other functions as well. > >> > > > > I'm not sure we would need a new abstraction here. > > Both UI plugins and engine plugins need some API to do basic > > operations, and have access to different properties in the engine. > > +1, that's exactly what i've suggested to begin with. > The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way. > > In the UI plguins implementation, we gave this API, and in addition > > created a REST session to be used in order to do more > > sophisticated operations. > > I think we should probably do the same for engine plugins, > > giving the basic API, and giving a REST session for more advanced > > operations. > > The engine plugin may also have another 3rd party application it > > interacts with, and it would be able to share this session with > > it, > > allowing it to perform different operations on the engine. It would > > obviously be easy to do that using the Java SDK in the engine > > side, > > without creating a new layer of abstraction. > > true, but the thing is that java-sdk designed to work with rest-api, > and what Doron is trying to do > is saving round-trip of engine->sdk->api->engine by enabling extra > layer in sdk that will work not via HTTP, > but natively with RESTeasy (REST framework we using in api), the > disadvantages of such design are: > > 1. working with java-sdk via JNI (walking out from container to > client application - sdk) > 2. hacking RESTeasy by: > 2.1 working with underlying (not public/backward compatible) > interfaces & using JNI as well > 2.2 most likely maintaining code working with RESTeasy on every > new (RESTeasy) release by reverse > engineering new changes/behaviour of this framework > 2.3 making assumptions on code invocations to emulate > GET/POST/PUT/DELETE HTTP calls > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > therefore i think that having own private API in engine for that is a > much better solution. > > > I assume the 3rd party application will use either the Java SDK, or > > another one, according the platform it is built upon, and in the > > "worst case", will interact directly with the API. > > > > > >>>> > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I would like to ask, if there have been discussions about an > >>>>>> option > >>>>>> to call REST API services directly from the Frontend (GWT > >>>>>> layer)? > >>>>>> GWT compiles Java frontend-side to > >>>>>> Javascript, calls to backend services are performed > >>>>>> "transparently" > >>>>>> by the framework using AJAX support. But, there is still a > >>>>>> need > >>>>>> to > >>>>>> have a special set of data objects > >>>>>> and the server-side logic can duplicate. > >>>>>> > >>>>>> Java REST API SDK enables to build "thick" client. The calls > >>>>>> are > >>>>>> realized using e.g. Apache HttClient and supported libraries. > >>>>>> I > >>>>>> think the requirements of GWT can be a > >>>>>> little bit different, but something overlaps. > >>>>>> > >>>>>> I found several links about REST API support from GWT, so > >>>>>> there > >>>>>> is > >>>>>> something for inspiration... > >>>>>> > >>>>>> - http://www.spiffyui.org/ > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > >>>>>> - http://code.google.com/p/gwt-rest/ > >>>>>> - http://restygwt.fusesource.org/ > >>>>>> > >>>>>> But, do you think it would be useful and what drawbacks can > >>>>>> occur > >>>>>> (authentication, authorization, response times, need to > >>>>>> support > >>>>>> larger set of services, painful > >>>>>> refactoring, ...)? > >>>>>> > >>>>>> Regards, > >>>>>> Libor > >>>>>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ovedo at redhat.com Sun Feb 24 13:01:19 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 24 Feb 2013 08:01:19 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <1947542298.8405100.1361704812489.JavaMail.root@redhat.com> Message-ID: <132421718.6971303.1361710879301.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: "Michael Pasternak" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, arch at ovirt.org > Sent: Sunday, February 24, 2013 1:20:12 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Michael Pasternak" > > To: "Oved Ourfalli" > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > Sent: Sunday, February 24, 2013 9:47:28 AM > > Subject: Re: [Engine-devel] REST API calls from > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Doron Fediuck" > > >> To: "Michael Pasternak" > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > >> Subject: Re: [Engine-devel] REST API calls from > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Michael Pasternak" > > >>> To: "Doron Fediuck" > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > >>> Subject: Re: [Engine-devel] REST API calls from > > >>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Michael Pasternak" > > >>>>> To: "Libor Spevak" > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI > > >>>>> > > >>>>> > > >>>>> Hi Libor, > > >>>>> > > >>>>> This issue came across in one of the conversations i had with > > >>>>> UX > > >>>>> folks, but since we didn't end > > >>>>> up with any conclusion/road map (nor discussed it properly to > > >>>>> hear > > >>>>> other thoughts), this is a perfect > > >>>>> place to start this discussion, > > >>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX calls > > >>>>> --------------------------------------------------- > > >>>>> > > >>>>> pros > > >>>>> ==== > > >>>>> > > >>>>> - api data objects can be reused by generating java classes > > >>>>> (using > > >>>>> jaxb) from the rest schema [1] > > >>>>> - no backend logic will be duplicated as api abstracts the > > >>>>> backend > > >>>>> exposing RESTful collection/resources to operate on > > >>>>> - development against api is "easy" as api describes itself > > >>>>> in > > >>>>> RSDL > > >>>>> [2] > > >>>>> > > >>>>> cons > > >>>>> ==== > > >>>>> > > >>>>> - implementing transport layer (HTTP) under GWT > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer > > >>>>> - implementing own error handling mechanism > > >>>>> - implementing REST callback mechanism (in GWT) > > >>>>> - constant maintenance of the data objects generated from the > > >>>>> api > > >>>>> - painful for Java developers > > >>>>> > > >>>>> Java-SDK > > >>>>> -------- > > >>>>> > > >>>>> pros > > >>>>> ==== > > >>>>> > > >>>>> - abstracts transport layer (leaving developer in standard > > >>>>> Java > > >>>>> api) > > >>>>> - typesafe code (no need to mess with XML bulks) > > >>>>> - has own data objects to work with > > >>>>> - abstracts authentication/authorization > > >>>>> (kerberos/cookie/session/etc.) > > >>>>> - since SDK is auto-generated, it can be easily extended with > > >>>>> required > > >>>>> features to support UI (such as callback infrastructure for > > >>>>> instance) > > >>>>> > > >>>>> cons > > >>>>> ==== > > >>>>> > > >>>>> - has to be converted in to Javascript (not sure what the > > >>>>> impacts > > >>>>> are > > >>>>> in terms of AJAX calls/etc.) > > >>>>> - probably much more cons that we're not aware of and will > > >>>>> have > > >>>>> to > > >>>>> figure out with POC > > >>>>> > > >>>>> > > >>>>> thoughts? > > >>>>> > > >>>>> [1] http[s]://server[:port]/api?schema > > >>>>> [2] http[s]://server[:port]/api?rsdl > > >>>>> > > >>>> > > >>>> Although started as a UI request, there are other needs who > > >>>> wish > > >>>> to use API calls with a different transport. For example a > > >>>> backend > > >>>> hook which gets a REST entry point it can use to fetch for > > >>>> additional > > >>>> data, or perform actions. In this case I'd expect an internal > > >>>> connection > > >>>> rather than creating additional connections. > > >>>> How would you resolve it generically enough in this context? > > >>> > > >>> Doron, > > >>> > > >>> I believe your approach a bit different, UX folks seeking for a > > >>> convenient > > >>> way of communicating with ovirt public api, e.g closing > > >>> api<->GUI > > >>> gap, and > > >>> theirs alternatives where native HTTP layer or Java-SDK based > > >>> framework, > > >>> while what you need is in-process channel to communicate with > > >>> the > > >>> engine itself, > > >>> > > >>> i understanding your will of using stable api for this > > >>> (RESTapi), > > >>> but > > >>> not > > >>> sure that doing this via JavaSDK is a good way to go simply > > >>> because > > >>> SDK is > > >>> designed to operate in a client-space, while what you need is a > > >>> server-space > > >>> bridge for that. > > >>> > > >> > > >> Michael, true but... > > >> Thinking about it differently both UI and hooks needs a client. > > >> The underlying protocols should be abstracted. This is something > > >> which will serve other functions as well. > > >> > > > > > > I'm not sure we would need a new abstraction here. > > > Both UI plugins and engine plugins need some API to do basic > > > operations, and have access to different properties in the > > > engine. > > > > +1, that's exactly what i've suggested to begin with. > > > > The only issue is that UI plugins and engine plugins shave different > expectations > from performance point of view. If UI is willing to wait for a > refresh that may > take too long for engine plugins, which would prefer to get the > information as > soon as possible without going into various communication layers > which are not > always needed. So again- a simple solution which enables transports > layers to > be replaced may serve more than one functionality in a better way. > Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request). > > > In the UI plguins implementation, we gave this API, and in > > > addition > > > created a REST session to be used in order to do more > > > sophisticated operations. > > > I think we should probably do the same for engine plugins, > > > giving the basic API, and giving a REST session for more advanced > > > operations. > > > The engine plugin may also have another 3rd party application it > > > interacts with, and it would be able to share this session with > > > it, > > > allowing it to perform different operations on the engine. It > > > would > > > obviously be easy to do that using the Java SDK in the engine > > > side, > > > without creating a new layer of abstraction. > > > > true, but the thing is that java-sdk designed to work with > > rest-api, > > and what Doron is trying to do > > is saving round-trip of engine->sdk->api->engine by enabling extra > > layer in sdk that will work not via HTTP, > > but natively with RESTeasy (REST framework we using in api), the > > disadvantages of such design are: > > > > 1. working with java-sdk via JNI (walking out from container to > > client application - sdk) > > 2. hacking RESTeasy by: > > 2.1 working with underlying (not public/backward compatible) > > interfaces & using JNI as well > > 2.2 most likely maintaining code working with RESTeasy on every > > new (RESTeasy) release by reverse > > engineering new changes/behaviour of this framework > > 2.3 making assumptions on code invocations to emulate > > GET/POST/PUT/DELETE HTTP calls > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > therefore i think that having own private API in engine for that is > > a > > much better solution. > > > > > I assume the 3rd party application will use either the Java SDK, > > > or > > > another one, according the platform it is built upon, and in the > > > "worst case", will interact directly with the API. > > > > > > > > >>>> > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I would like to ask, if there have been discussions about an > > >>>>>> option > > >>>>>> to call REST API services directly from the Frontend (GWT > > >>>>>> layer)? > > >>>>>> GWT compiles Java frontend-side to > > >>>>>> Javascript, calls to backend services are performed > > >>>>>> "transparently" > > >>>>>> by the framework using AJAX support. But, there is still a > > >>>>>> need > > >>>>>> to > > >>>>>> have a special set of data objects > > >>>>>> and the server-side logic can duplicate. > > >>>>>> > > >>>>>> Java REST API SDK enables to build "thick" client. The calls > > >>>>>> are > > >>>>>> realized using e.g. Apache HttClient and supported > > >>>>>> libraries. > > >>>>>> I > > >>>>>> think the requirements of GWT can be a > > >>>>>> little bit different, but something overlaps. > > >>>>>> > > >>>>>> I found several links about REST API support from GWT, so > > >>>>>> there > > >>>>>> is > > >>>>>> something for inspiration... > > >>>>>> > > >>>>>> - http://www.spiffyui.org/ > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > > >>>>>> - http://code.google.com/p/gwt-rest/ > > >>>>>> - http://restygwt.fusesource.org/ > > >>>>>> > > >>>>>> But, do you think it would be useful and what drawbacks can > > >>>>>> occur > > >>>>>> (authentication, authorization, response times, need to > > >>>>>> support > > >>>>>> larger set of services, painful > > >>>>>> refactoring, ...)? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Libor > > >>>>>> > > >> _______________________________________________ > > >> Engine-devel mailing list > > >> Engine-devel at ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > > > > > -- > > > > Michael Pasternak > > RedHat, ENG-Virtualization R&D > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From dfediuck at redhat.com Sun Feb 24 13:55:28 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 24 Feb 2013 08:55:28 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <132421718.6971303.1361710879301.JavaMail.root@redhat.com> Message-ID: <1891808602.8412695.1361714128915.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Oved Ourfalli" > To: "Doron Fediuck" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Sunday, February 24, 2013 3:01:19 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Michael Pasternak" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, > > arch at ovirt.org > > Sent: Sunday, February 24, 2013 1:20:12 PM > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > ----- Original Message ----- > > > From: "Michael Pasternak" > > > To: "Oved Ourfalli" > > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > > Sent: Sunday, February 24, 2013 9:47:28 AM > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Doron Fediuck" > > > >> To: "Michael Pasternak" > > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > > >> Subject: Re: [Engine-devel] REST API calls from > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Michael Pasternak" > > > >>> To: "Doron Fediuck" > > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > > >>> Subject: Re: [Engine-devel] REST API calls from > > > >>> > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > >>>> > > > >>>> > > > >>>> ----- Original Message ----- > > > >>>>> From: "Michael Pasternak" > > > >>>>> To: "Libor Spevak" > > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI > > > >>>>> > > > >>>>> > > > >>>>> Hi Libor, > > > >>>>> > > > >>>>> This issue came across in one of the conversations i had > > > >>>>> with > > > >>>>> UX > > > >>>>> folks, but since we didn't end > > > >>>>> up with any conclusion/road map (nor discussed it properly > > > >>>>> to > > > >>>>> hear > > > >>>>> other thoughts), this is a perfect > > > >>>>> place to start this discussion, > > > >>>>> > > > >>>>> Intuitively REST is a way to go with GWT AJAX calls > > > >>>>> --------------------------------------------------- > > > >>>>> > > > >>>>> pros > > > >>>>> ==== > > > >>>>> > > > >>>>> - api data objects can be reused by generating java classes > > > >>>>> (using > > > >>>>> jaxb) from the rest schema [1] > > > >>>>> - no backend logic will be duplicated as api abstracts the > > > >>>>> backend > > > >>>>> exposing RESTful collection/resources to operate on > > > >>>>> - development against api is "easy" as api describes itself > > > >>>>> in > > > >>>>> RSDL > > > >>>>> [2] > > > >>>>> > > > >>>>> cons > > > >>>>> ==== > > > >>>>> > > > >>>>> - implementing transport layer (HTTP) under GWT > > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer > > > >>>>> - implementing own error handling mechanism > > > >>>>> - implementing REST callback mechanism (in GWT) > > > >>>>> - constant maintenance of the data objects generated from > > > >>>>> the > > > >>>>> api > > > >>>>> - painful for Java developers > > > >>>>> > > > >>>>> Java-SDK > > > >>>>> -------- > > > >>>>> > > > >>>>> pros > > > >>>>> ==== > > > >>>>> > > > >>>>> - abstracts transport layer (leaving developer in standard > > > >>>>> Java > > > >>>>> api) > > > >>>>> - typesafe code (no need to mess with XML bulks) > > > >>>>> - has own data objects to work with > > > >>>>> - abstracts authentication/authorization > > > >>>>> (kerberos/cookie/session/etc.) > > > >>>>> - since SDK is auto-generated, it can be easily extended > > > >>>>> with > > > >>>>> required > > > >>>>> features to support UI (such as callback infrastructure > > > >>>>> for > > > >>>>> instance) > > > >>>>> > > > >>>>> cons > > > >>>>> ==== > > > >>>>> > > > >>>>> - has to be converted in to Javascript (not sure what the > > > >>>>> impacts > > > >>>>> are > > > >>>>> in terms of AJAX calls/etc.) > > > >>>>> - probably much more cons that we're not aware of and will > > > >>>>> have > > > >>>>> to > > > >>>>> figure out with POC > > > >>>>> > > > >>>>> > > > >>>>> thoughts? > > > >>>>> > > > >>>>> [1] http[s]://server[:port]/api?schema > > > >>>>> [2] http[s]://server[:port]/api?rsdl > > > >>>>> > > > >>>> > > > >>>> Although started as a UI request, there are other needs who > > > >>>> wish > > > >>>> to use API calls with a different transport. For example a > > > >>>> backend > > > >>>> hook which gets a REST entry point it can use to fetch for > > > >>>> additional > > > >>>> data, or perform actions. In this case I'd expect an > > > >>>> internal > > > >>>> connection > > > >>>> rather than creating additional connections. > > > >>>> How would you resolve it generically enough in this context? > > > >>> > > > >>> Doron, > > > >>> > > > >>> I believe your approach a bit different, UX folks seeking for > > > >>> a > > > >>> convenient > > > >>> way of communicating with ovirt public api, e.g closing > > > >>> api<->GUI > > > >>> gap, and > > > >>> theirs alternatives where native HTTP layer or Java-SDK based > > > >>> framework, > > > >>> while what you need is in-process channel to communicate with > > > >>> the > > > >>> engine itself, > > > >>> > > > >>> i understanding your will of using stable api for this > > > >>> (RESTapi), > > > >>> but > > > >>> not > > > >>> sure that doing this via JavaSDK is a good way to go simply > > > >>> because > > > >>> SDK is > > > >>> designed to operate in a client-space, while what you need is > > > >>> a > > > >>> server-space > > > >>> bridge for that. > > > >>> > > > >> > > > >> Michael, true but... > > > >> Thinking about it differently both UI and hooks needs a > > > >> client. > > > >> The underlying protocols should be abstracted. This is > > > >> something > > > >> which will serve other functions as well. > > > >> > > > > > > > > I'm not sure we would need a new abstraction here. > > > > Both UI plugins and engine plugins need some API to do basic > > > > operations, and have access to different properties in the > > > > engine. > > > > > > +1, that's exactly what i've suggested to begin with. > > > > > > > The only issue is that UI plugins and engine plugins shave > > different > > expectations > > from performance point of view. If UI is willing to wait for a > > refresh that may > > take too long for engine plugins, which would prefer to get the > > information as > > soon as possible without going into various communication layers > > which are not > > always needed. So again- a simple solution which enables transports > > layers to > > be replaced may serve more than one functionality in a better way. > > > > Let's start with the simple solution. We don't know yet who will the > plugins, how would they be used, and whether using the SDK will be a > bottleneck of any kind. If the proposed solution is to support > different transport layers while still using the SDK, then it is an > extension we can always do in the future, if we find it of high > benefit. > (btw, regardless of that, the API/SDK is now faster than in the past, > as we support REST sessions, which removes the need to > re-authenticate upon each API request). > Oved, we have pretty good idea on how it will be used and what will create performance hits. Otherwise we wouldn't have had this thread. > > > > In the UI plguins implementation, we gave this API, and in > > > > addition > > > > created a REST session to be used in order to do more > > > > sophisticated operations. > > > > I think we should probably do the same for engine plugins, > > > > giving the basic API, and giving a REST session for more > > > > advanced > > > > operations. > > > > The engine plugin may also have another 3rd party application > > > > it > > > > interacts with, and it would be able to share this session with > > > > it, > > > > allowing it to perform different operations on the engine. It > > > > would > > > > obviously be easy to do that using the Java SDK in the engine > > > > side, > > > > without creating a new layer of abstraction. > > > > > > true, but the thing is that java-sdk designed to work with > > > rest-api, > > > and what Doron is trying to do > > > is saving round-trip of engine->sdk->api->engine by enabling > > > extra > > > layer in sdk that will work not via HTTP, > > > but natively with RESTeasy (REST framework we using in api), the > > > disadvantages of such design are: > > > > > > 1. working with java-sdk via JNI (walking out from container to > > > client application - sdk) > > > 2. hacking RESTeasy by: > > > 2.1 working with underlying (not public/backward compatible) > > > interfaces & using JNI as well > > > 2.2 most likely maintaining code working with RESTeasy on > > > every > > > new (RESTeasy) release by reverse > > > engineering new changes/behaviour of this framework > > > 2.3 making assumptions on code invocations to emulate > > > GET/POST/PUT/DELETE HTTP calls > > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > > > therefore i think that having own private API in engine for that > > > is > > > a > > > much better solution. > > > > > > > I assume the 3rd party application will use either the Java > > > > SDK, > > > > or > > > > another one, according the platform it is built upon, and in > > > > the > > > > "worst case", will interact directly with the API. > > > > > > > > > > > >>>> > > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> I would like to ask, if there have been discussions about > > > >>>>>> an > > > >>>>>> option > > > >>>>>> to call REST API services directly from the Frontend (GWT > > > >>>>>> layer)? > > > >>>>>> GWT compiles Java frontend-side to > > > >>>>>> Javascript, calls to backend services are performed > > > >>>>>> "transparently" > > > >>>>>> by the framework using AJAX support. But, there is still a > > > >>>>>> need > > > >>>>>> to > > > >>>>>> have a special set of data objects > > > >>>>>> and the server-side logic can duplicate. > > > >>>>>> > > > >>>>>> Java REST API SDK enables to build "thick" client. The > > > >>>>>> calls > > > >>>>>> are > > > >>>>>> realized using e.g. Apache HttClient and supported > > > >>>>>> libraries. > > > >>>>>> I > > > >>>>>> think the requirements of GWT can be a > > > >>>>>> little bit different, but something overlaps. > > > >>>>>> > > > >>>>>> I found several links about REST API support from GWT, so > > > >>>>>> there > > > >>>>>> is > > > >>>>>> something for inspiration... > > > >>>>>> > > > >>>>>> - http://www.spiffyui.org/ > > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > > > >>>>>> - http://code.google.com/p/gwt-rest/ > > > >>>>>> - http://restygwt.fusesource.org/ > > > >>>>>> > > > >>>>>> But, do you think it would be useful and what drawbacks > > > >>>>>> can > > > >>>>>> occur > > > >>>>>> (authentication, authorization, response times, need to > > > >>>>>> support > > > >>>>>> larger set of services, painful > > > >>>>>> refactoring, ...)? > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Libor > > > >>>>>> From ovedo at redhat.com Sun Feb 24 21:56:49 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 24 Feb 2013 16:56:49 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <1891808602.8412695.1361714128915.JavaMail.root@redhat.com> Message-ID: <1605013790.7186572.1361743009535.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Sunday, February 24, 2013 3:55:28 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Oved Ourfalli" > > To: "Doron Fediuck" > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > Sent: Sunday, February 24, 2013 3:01:19 PM > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > ----- Original Message ----- > > > From: "Doron Fediuck" > > > To: "Michael Pasternak" > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, > > > arch at ovirt.org > > > Sent: Sunday, February 24, 2013 1:20:12 PM > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Michael Pasternak" > > > > To: "Oved Ourfalli" > > > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > Sent: Sunday, February 24, 2013 9:47:28 AM > > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Doron Fediuck" > > > > >> To: "Michael Pasternak" > > > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > > > >> Subject: Re: [Engine-devel] REST API calls from > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >>> From: "Michael Pasternak" > > > > >>> To: "Doron Fediuck" > > > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > > > >>> Subject: Re: [Engine-devel] REST API calls from > > > > >>> > > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > >>>> > > > > >>>> > > > > >>>> ----- Original Message ----- > > > > >>>>> From: "Michael Pasternak" > > > > >>>>> To: "Libor Spevak" > > > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > > > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI > > > > >>>>> > > > > >>>>> > > > > >>>>> Hi Libor, > > > > >>>>> > > > > >>>>> This issue came across in one of the conversations i had > > > > >>>>> with > > > > >>>>> UX > > > > >>>>> folks, but since we didn't end > > > > >>>>> up with any conclusion/road map (nor discussed it > > > > >>>>> properly > > > > >>>>> to > > > > >>>>> hear > > > > >>>>> other thoughts), this is a perfect > > > > >>>>> place to start this discussion, > > > > >>>>> > > > > >>>>> Intuitively REST is a way to go with GWT AJAX calls > > > > >>>>> --------------------------------------------------- > > > > >>>>> > > > > >>>>> pros > > > > >>>>> ==== > > > > >>>>> > > > > >>>>> - api data objects can be reused by generating java > > > > >>>>> classes > > > > >>>>> (using > > > > >>>>> jaxb) from the rest schema [1] > > > > >>>>> - no backend logic will be duplicated as api abstracts > > > > >>>>> the > > > > >>>>> backend > > > > >>>>> exposing RESTful collection/resources to operate on > > > > >>>>> - development against api is "easy" as api describes > > > > >>>>> itself > > > > >>>>> in > > > > >>>>> RSDL > > > > >>>>> [2] > > > > >>>>> > > > > >>>>> cons > > > > >>>>> ==== > > > > >>>>> > > > > >>>>> - implementing transport layer (HTTP) under GWT > > > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer > > > > >>>>> - implementing own error handling mechanism > > > > >>>>> - implementing REST callback mechanism (in GWT) > > > > >>>>> - constant maintenance of the data objects generated from > > > > >>>>> the > > > > >>>>> api > > > > >>>>> - painful for Java developers > > > > >>>>> > > > > >>>>> Java-SDK > > > > >>>>> -------- > > > > >>>>> > > > > >>>>> pros > > > > >>>>> ==== > > > > >>>>> > > > > >>>>> - abstracts transport layer (leaving developer in > > > > >>>>> standard > > > > >>>>> Java > > > > >>>>> api) > > > > >>>>> - typesafe code (no need to mess with XML bulks) > > > > >>>>> - has own data objects to work with > > > > >>>>> - abstracts authentication/authorization > > > > >>>>> (kerberos/cookie/session/etc.) > > > > >>>>> - since SDK is auto-generated, it can be easily extended > > > > >>>>> with > > > > >>>>> required > > > > >>>>> features to support UI (such as callback infrastructure > > > > >>>>> for > > > > >>>>> instance) > > > > >>>>> > > > > >>>>> cons > > > > >>>>> ==== > > > > >>>>> > > > > >>>>> - has to be converted in to Javascript (not sure what the > > > > >>>>> impacts > > > > >>>>> are > > > > >>>>> in terms of AJAX calls/etc.) > > > > >>>>> - probably much more cons that we're not aware of and > > > > >>>>> will > > > > >>>>> have > > > > >>>>> to > > > > >>>>> figure out with POC > > > > >>>>> > > > > >>>>> > > > > >>>>> thoughts? > > > > >>>>> > > > > >>>>> [1] http[s]://server[:port]/api?schema > > > > >>>>> [2] http[s]://server[:port]/api?rsdl > > > > >>>>> > > > > >>>> > > > > >>>> Although started as a UI request, there are other needs > > > > >>>> who > > > > >>>> wish > > > > >>>> to use API calls with a different transport. For example a > > > > >>>> backend > > > > >>>> hook which gets a REST entry point it can use to fetch for > > > > >>>> additional > > > > >>>> data, or perform actions. In this case I'd expect an > > > > >>>> internal > > > > >>>> connection > > > > >>>> rather than creating additional connections. > > > > >>>> How would you resolve it generically enough in this > > > > >>>> context? > > > > >>> > > > > >>> Doron, > > > > >>> > > > > >>> I believe your approach a bit different, UX folks seeking > > > > >>> for > > > > >>> a > > > > >>> convenient > > > > >>> way of communicating with ovirt public api, e.g closing > > > > >>> api<->GUI > > > > >>> gap, and > > > > >>> theirs alternatives where native HTTP layer or Java-SDK > > > > >>> based > > > > >>> framework, > > > > >>> while what you need is in-process channel to communicate > > > > >>> with > > > > >>> the > > > > >>> engine itself, > > > > >>> > > > > >>> i understanding your will of using stable api for this > > > > >>> (RESTapi), > > > > >>> but > > > > >>> not > > > > >>> sure that doing this via JavaSDK is a good way to go simply > > > > >>> because > > > > >>> SDK is > > > > >>> designed to operate in a client-space, while what you need > > > > >>> is > > > > >>> a > > > > >>> server-space > > > > >>> bridge for that. > > > > >>> > > > > >> > > > > >> Michael, true but... > > > > >> Thinking about it differently both UI and hooks needs a > > > > >> client. > > > > >> The underlying protocols should be abstracted. This is > > > > >> something > > > > >> which will serve other functions as well. > > > > >> > > > > > > > > > > I'm not sure we would need a new abstraction here. > > > > > Both UI plugins and engine plugins need some API to do basic > > > > > operations, and have access to different properties in the > > > > > engine. > > > > > > > > +1, that's exactly what i've suggested to begin with. > > > > > > > > > > The only issue is that UI plugins and engine plugins shave > > > different > > > expectations > > > from performance point of view. If UI is willing to wait for a > > > refresh that may > > > take too long for engine plugins, which would prefer to get the > > > information as > > > soon as possible without going into various communication layers > > > which are not > > > always needed. So again- a simple solution which enables > > > transports > > > layers to > > > be replaced may serve more than one functionality in a better > > > way. > > > > > > > Let's start with the simple solution. We don't know yet who will > > the > > plugins, how would they be used, and whether using the SDK will be > > a > > bottleneck of any kind. If the proposed solution is to support > > different transport layers while still using the SDK, then it is an > > extension we can always do in the future, if we find it of high > > benefit. > > (btw, regardless of that, the API/SDK is now faster than in the > > past, > > as we support REST sessions, which removes the need to > > re-authenticate upon each API request). > > > > Oved, we have pretty good idea on how it will be used and what will > create performance hits. Otherwise we wouldn't have had this thread. > If so, it would be nice if you share this information on the thread as well... some use-cases, some statistics you may have on the current performance, and on the performance requirements, and etc. I'm not saying that you're wrong... just saying I wasn't convinced it is really necessary. Thank you, Oved > > > > > In the UI plguins implementation, we gave this API, and in > > > > > addition > > > > > created a REST session to be used in order to do more > > > > > sophisticated operations. > > > > > I think we should probably do the same for engine plugins, > > > > > giving the basic API, and giving a REST session for more > > > > > advanced > > > > > operations. > > > > > The engine plugin may also have another 3rd party application > > > > > it > > > > > interacts with, and it would be able to share this session > > > > > with > > > > > it, > > > > > allowing it to perform different operations on the engine. It > > > > > would > > > > > obviously be easy to do that using the Java SDK in the engine > > > > > side, > > > > > without creating a new layer of abstraction. > > > > > > > > true, but the thing is that java-sdk designed to work with > > > > rest-api, > > > > and what Doron is trying to do > > > > is saving round-trip of engine->sdk->api->engine by enabling > > > > extra > > > > layer in sdk that will work not via HTTP, > > > > but natively with RESTeasy (REST framework we using in api), > > > > the > > > > disadvantages of such design are: > > > > > > > > 1. working with java-sdk via JNI (walking out from container to > > > > client application - sdk) > > > > 2. hacking RESTeasy by: > > > > 2.1 working with underlying (not public/backward compatible) > > > > interfaces & using JNI as well > > > > 2.2 most likely maintaining code working with RESTeasy on > > > > every > > > > new (RESTeasy) release by reverse > > > > engineering new changes/behaviour of this framework > > > > 2.3 making assumptions on code invocations to emulate > > > > GET/POST/PUT/DELETE HTTP calls > > > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > > > > > therefore i think that having own private API in engine for > > > > that > > > > is > > > > a > > > > much better solution. > > > > > > > > > I assume the 3rd party application will use either the Java > > > > > SDK, > > > > > or > > > > > another one, according the platform it is built upon, and in > > > > > the > > > > > "worst case", will interact directly with the API. > > > > > > > > > > > > > > >>>> > > > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > > > > >>>>>> Hi, > > > > >>>>>> > > > > >>>>>> I would like to ask, if there have been discussions > > > > >>>>>> about > > > > >>>>>> an > > > > >>>>>> option > > > > >>>>>> to call REST API services directly from the Frontend > > > > >>>>>> (GWT > > > > >>>>>> layer)? > > > > >>>>>> GWT compiles Java frontend-side to > > > > >>>>>> Javascript, calls to backend services are performed > > > > >>>>>> "transparently" > > > > >>>>>> by the framework using AJAX support. But, there is still > > > > >>>>>> a > > > > >>>>>> need > > > > >>>>>> to > > > > >>>>>> have a special set of data objects > > > > >>>>>> and the server-side logic can duplicate. > > > > >>>>>> > > > > >>>>>> Java REST API SDK enables to build "thick" client. The > > > > >>>>>> calls > > > > >>>>>> are > > > > >>>>>> realized using e.g. Apache HttClient and supported > > > > >>>>>> libraries. > > > > >>>>>> I > > > > >>>>>> think the requirements of GWT can be a > > > > >>>>>> little bit different, but something overlaps. > > > > >>>>>> > > > > >>>>>> I found several links about REST API support from GWT, > > > > >>>>>> so > > > > >>>>>> there > > > > >>>>>> is > > > > >>>>>> something for inspiration... > > > > >>>>>> > > > > >>>>>> - http://www.spiffyui.org/ > > > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > > > > >>>>>> - http://code.google.com/p/gwt-rest/ > > > > >>>>>> - http://restygwt.fusesource.org/ > > > > >>>>>> > > > > >>>>>> But, do you think it would be useful and what drawbacks > > > > >>>>>> can > > > > >>>>>> occur > > > > >>>>>> (authentication, authorization, response times, need to > > > > >>>>>> support > > > > >>>>>> larger set of services, painful > > > > >>>>>> refactoring, ...)? > > > > >>>>>> > > > > >>>>>> Regards, > > > > >>>>>> Libor > > > > >>>>>> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Mon Feb 25 10:33:01 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 25 Feb 2013 12:33:01 +0200 Subject: [Engine-devel] REST API calls from In-Reply-To: <132421718.6971303.1361710879301.JavaMail.root@redhat.com> References: <132421718.6971303.1361710879301.JavaMail.root@redhat.com> Message-ID: <512B3DDD.90301@redhat.com> On 02/24/2013 03:01 PM, Oved Ourfalli wrote: > > ----- Original Message ----- >> > From: "Doron Fediuck" >> > To: "Michael Pasternak" >> > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, arch at ovirt.org >> > Sent: Sunday, February 24, 2013 1:20:12 PM >> > Subject: Re: [Engine-devel] REST API calls from >> > >> > >> > >> > ----- Original Message ----- >>> > > From: "Michael Pasternak" >>> > > To: "Oved Ourfalli" >>> > > Cc: engine-devel at ovirt.org, arch at ovirt.org >>> > > Sent: Sunday, February 24, 2013 9:47:28 AM >>> > > Subject: Re: [Engine-devel] REST API calls from >>> > > >>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: >>>> > > > >>>> > > > >>>> > > > ----- Original Message ----- >>>>> > > >> From: "Doron Fediuck" >>>>> > > >> To: "Michael Pasternak" >>>>> > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org >>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM >>>>> > > >> Subject: Re: [Engine-devel] REST API calls from >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> ----- Original Message ----- >>>>>> > > >>> From: "Michael Pasternak" >>>>>> > > >>> To: "Doron Fediuck" >>>>>> > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org >>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM >>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from >>>>>> > > >>> >>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >>>>>>> > > >>>> >>>>>>> > > >>>> >>>>>>> > > >>>> ----- Original Message ----- >>>>>>>> > > >>>>> From: "Michael Pasternak" >>>>>>>> > > >>>>> To: "Libor Spevak" >>>>>>>> > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org >>>>>>>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>>>>>>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> Hi Libor, >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> This issue came across in one of the conversations i had with >>>>>>>> > > >>>>> UX >>>>>>>> > > >>>>> folks, but since we didn't end >>>>>>>> > > >>>>> up with any conclusion/road map (nor discussed it properly to >>>>>>>> > > >>>>> hear >>>>>>>> > > >>>>> other thoughts), this is a perfect >>>>>>>> > > >>>>> place to start this discussion, >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX calls >>>>>>>> > > >>>>> --------------------------------------------------- >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> pros >>>>>>>> > > >>>>> ==== >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> - api data objects can be reused by generating java classes >>>>>>>> > > >>>>> (using >>>>>>>> > > >>>>> jaxb) from the rest schema [1] >>>>>>>> > > >>>>> - no backend logic will be duplicated as api abstracts the >>>>>>>> > > >>>>> backend >>>>>>>> > > >>>>> exposing RESTful collection/resources to operate on >>>>>>>> > > >>>>> - development against api is "easy" as api describes itself >>>>>>>> > > >>>>> in >>>>>>>> > > >>>>> RSDL >>>>>>>> > > >>>>> [2] >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> cons >>>>>>>> > > >>>>> ==== >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> - implementing transport layer (HTTP) under GWT >>>>>>>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer >>>>>>>> > > >>>>> - implementing own error handling mechanism >>>>>>>> > > >>>>> - implementing REST callback mechanism (in GWT) >>>>>>>> > > >>>>> - constant maintenance of the data objects generated from the >>>>>>>> > > >>>>> api >>>>>>>> > > >>>>> - painful for Java developers >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> Java-SDK >>>>>>>> > > >>>>> -------- >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> pros >>>>>>>> > > >>>>> ==== >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> - abstracts transport layer (leaving developer in standard >>>>>>>> > > >>>>> Java >>>>>>>> > > >>>>> api) >>>>>>>> > > >>>>> - typesafe code (no need to mess with XML bulks) >>>>>>>> > > >>>>> - has own data objects to work with >>>>>>>> > > >>>>> - abstracts authentication/authorization >>>>>>>> > > >>>>> (kerberos/cookie/session/etc.) >>>>>>>> > > >>>>> - since SDK is auto-generated, it can be easily extended with >>>>>>>> > > >>>>> required >>>>>>>> > > >>>>> features to support UI (such as callback infrastructure for >>>>>>>> > > >>>>> instance) >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> cons >>>>>>>> > > >>>>> ==== >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> - has to be converted in to Javascript (not sure what the >>>>>>>> > > >>>>> impacts >>>>>>>> > > >>>>> are >>>>>>>> > > >>>>> in terms of AJAX calls/etc.) >>>>>>>> > > >>>>> - probably much more cons that we're not aware of and will >>>>>>>> > > >>>>> have >>>>>>>> > > >>>>> to >>>>>>>> > > >>>>> figure out with POC >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> thoughts? >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema >>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl >>>>>>>> > > >>>>> >>>>>>> > > >>>> >>>>>>> > > >>>> Although started as a UI request, there are other needs who >>>>>>> > > >>>> wish >>>>>>> > > >>>> to use API calls with a different transport. For example a >>>>>>> > > >>>> backend >>>>>>> > > >>>> hook which gets a REST entry point it can use to fetch for >>>>>>> > > >>>> additional >>>>>>> > > >>>> data, or perform actions. In this case I'd expect an internal >>>>>>> > > >>>> connection >>>>>>> > > >>>> rather than creating additional connections. >>>>>>> > > >>>> How would you resolve it generically enough in this context? >>>>>> > > >>> >>>>>> > > >>> Doron, >>>>>> > > >>> >>>>>> > > >>> I believe your approach a bit different, UX folks seeking for a >>>>>> > > >>> convenient >>>>>> > > >>> way of communicating with ovirt public api, e.g closing >>>>>> > > >>> api<->GUI >>>>>> > > >>> gap, and >>>>>> > > >>> theirs alternatives where native HTTP layer or Java-SDK based >>>>>> > > >>> framework, >>>>>> > > >>> while what you need is in-process channel to communicate with >>>>>> > > >>> the >>>>>> > > >>> engine itself, >>>>>> > > >>> >>>>>> > > >>> i understanding your will of using stable api for this >>>>>> > > >>> (RESTapi), >>>>>> > > >>> but >>>>>> > > >>> not >>>>>> > > >>> sure that doing this via JavaSDK is a good way to go simply >>>>>> > > >>> because >>>>>> > > >>> SDK is >>>>>> > > >>> designed to operate in a client-space, while what you need is a >>>>>> > > >>> server-space >>>>>> > > >>> bridge for that. >>>>>> > > >>> >>>>> > > >> >>>>> > > >> Michael, true but... >>>>> > > >> Thinking about it differently both UI and hooks needs a client. >>>>> > > >> The underlying protocols should be abstracted. This is something >>>>> > > >> which will serve other functions as well. >>>>> > > >> >>>> > > > >>>> > > > I'm not sure we would need a new abstraction here. >>>> > > > Both UI plugins and engine plugins need some API to do basic >>>> > > > operations, and have access to different properties in the >>>> > > > engine. >>> > > >>> > > +1, that's exactly what i've suggested to begin with. >>> > > >> > >> > The only issue is that UI plugins and engine plugins shave different >> > expectations >> > from performance point of view. If UI is willing to wait for a >> > refresh that may >> > take too long for engine plugins, which would prefer to get the >> > information as >> > soon as possible without going into various communication layers >> > which are not >> > always needed. So again- a simple solution which enables transports >> > layers to >> > be replaced may serve more than one functionality in a better way. >> > > Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. > (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request). > true, but the real bottleneck is sending XML bulks over the wire + bi-directional marshalling X 2 (engine<->api + api<->xml). -- Michael Pasternak RedHat, ENG-Virtualization R&D From danken at redhat.com Mon Feb 25 10:34:46 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 25 Feb 2013 12:34:46 +0200 Subject: vdsm networking changes proposal In-Reply-To: <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> References: <999203743.6904373.1360277663937.JavaMail.root@redhat.com> <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> Message-ID: <20130225103446.GC11422@redhat.com> On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > Hello Antoni, > > Great work! > I am very excited we are going this route, it is first of many to allow us to be run on different distributions. > I apologize I got to this so late. > > Notes for the model, I am unsure if someone already noted. > > I think that the abstraction should be more than entity and properties. > > For example: > > nic is a network interface > bridge is a network interface and ports network interfaces > bound is a network interface and slave network interfaces > vlan is a network interface and vlan id > > network interface can have: > - name > - ip config > - state > - mtu > > this way it would be easier to share common code that handle pure interfaces. I agree with you - even though OOD is falling out of fashion in certain circles. > > I don't quite understand the 'Team' configurator, are you suggesting a > provider for each technology? Just as we may decide to move away from standard linux bridge to ovs-based bridging, we may switch from bonding to teaming. I do not think that we should do it now, but make sure that the design accomodates this. > > bridge > - iproute2 provider > - ovs provider > - ifcfg provider > > bond > - iproute2 > - team > - ovs > - ifcfg > > vlan > - iproute2 > - ovs > - ifcfg > > So we can get a configuration of: > bridge:iproute2 > bond:team > vlan:ovs I do not think that such complex combinations are of real interest. The client should not (currently) be allowed to request them. Some say that the specific combination that is used by Vdsm to implement the network should be defined in a config file. I think that a python file is good enough for that, at least for now. > > ? > > I also would like us to explore a future alternative of the network > configuration via crypto vpn directly from qemu to another qemu, the > idea is to have a kerberos like key per layer3(or layer2) destination, > while communication is encrypted at user space and sent to a flat > network. The advantage of this is that we manage logical network and > not physical network, while relaying on hardware to find the best > route to destination. The question is how and if we can provide this > via the suggestion abstraction. But maybe it is too soon to address > this kind of future. This is something completely different, as we say in Python. The nice thing about your idea, is that in the context of host network configuration we need nothing more than our current bridge-bond-nic. The sad thing about your idea, is that it would scale badly with the nubmer of virtual networks. If a new VM comes live and sends an ARP who-has broadcast message - which VMs should be bothered to attempt to decrypt it? > > For the open questions: > > 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. > > 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. > > 3. I think that if we can avoid aliases it would be nice. I wonder if everybody agrees that aliases are not needed. > > 4. Keeping the least persistence information would be flexible. I > would love to see a zero persistence mode available, for example if > management interface is dhcp or manually configured. > > I am very fond of the iproute2 configuration, and don't mind if > administrator configures the management interface manually. I think > this can supersede the ifcfg quite easily in most cases. In these rare > cases administrator use ovirt to modify the network interface we may > consider delegating persistence to totally different model. But as far > as I understand the problem is solely related to the management > connectivity, so we can implement a simple bootstrap of > non-persistence module to reconstruct the management network setup > from vdsm configuration instead of persisting it to the distribution > width configuration. > > Regards, > Alon Bar-Lev Thanks, Dan. From danken at redhat.com Mon Feb 25 10:49:19 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 25 Feb 2013 12:49:19 +0200 Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <5125EF21.1050205@linux.vnet.ibm.com> References: <1114476019.1374633.1361134653238.JavaMail.root@redhat.com> <1361179401.13448.54.camel@dhcp-29-7.brq.redhat.com> <5125DED8.9050706@linux.vnet.ibm.com> <5125EF21.1050205@linux.vnet.ibm.com> Message-ID: <20130225104919.GD11422@redhat.com> On Thu, Feb 21, 2013 at 05:55:45PM +0800, Mark Wu wrote: > On Thu 21 Feb 2013 04:46:16 PM CST, Mark Wu wrote: > >On 02/18/2013 05:23 PM, David Ja?a wrote: > > Sorry for coming to it so late. Happy new year! > I get the following comments and questions about the proposal. > > I suggest to add a field of top interface to the network, and only > apply IpConfig and mtu to it. I'm not sure how such an added field would help. Isn't the info already available within the stucture of interface objects? Or do you suggest a read-only field? I'd appreciate more details. > > For the openvswitch configurator, it needs assistance of iproute2 > because it can't configure ip/netmask/gw and mtu. Thanks, added to wiki. > > I can't figure out the point to allow different configurators except > openvswitch coexist. It could cause unnecessary complexity. I agree that we should decide on a very limited set of valid configurator combinations. > > In the proposal, the rollback mechanism can be used to persist > configuration for iproute2. Why do we still need NetworkManager? We may need NetworkManager. It is present and running by default on our target platforms -- inlcuding my laptop -- and it can be a bit rude to other services that try to configure network devices not through it. > > I think the solution of "iproute2 + openvswitch + serializing > configuration objects" can meet all our requirements. I remember > that Dan had a concern of > adding a new standard about it in previous discussion. Have we > already get agreement on it? Well, I'd say that I've caved in. I see no other way forward without introducing our own form of persisting network definitions. At least we keep our current setupNetworks API for that. Dan. From dfediuck at redhat.com Mon Feb 25 13:20:09 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 25 Feb 2013 08:20:09 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <512B3DDD.90301@redhat.com> Message-ID: <849405596.8862817.1361798409457.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Monday, February 25, 2013 12:33:01 PM > Subject: Re: [Engine-devel] REST API calls from > > On 02/24/2013 03:01 PM, Oved Ourfalli wrote: > > > > ----- Original Message ----- > >> > From: "Doron Fediuck" > >> > To: "Michael Pasternak" > >> > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, > >> > arch at ovirt.org > >> > Sent: Sunday, February 24, 2013 1:20:12 PM > >> > Subject: Re: [Engine-devel] REST API calls from > >> > > >> > > >> > > >> > ----- Original Message ----- > >>> > > From: "Michael Pasternak" > >>> > > To: "Oved Ourfalli" > >>> > > Cc: engine-devel at ovirt.org, arch at ovirt.org > >>> > > Sent: Sunday, February 24, 2013 9:47:28 AM > >>> > > Subject: Re: [Engine-devel] REST API calls from > >>> > > > >>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > >>>> > > > > >>>> > > > > >>>> > > > ----- Original Message ----- > >>>>> > > >> From: "Doron Fediuck" > >>>>> > > >> To: "Michael Pasternak" > >>>>> > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > >>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > >>>>> > > >> Subject: Re: [Engine-devel] REST API calls from > >>>>> > > >> > >>>>> > > >> > >>>>> > > >> > >>>>> > > >> ----- Original Message ----- > >>>>>> > > >>> From: "Michael Pasternak" > >>>>>> > > >>> To: "Doron Fediuck" > >>>>>> > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > >>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > >>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from > >>>>>> > > >>> > >>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > >>>>>>> > > >>>> > >>>>>>> > > >>>> > >>>>>>> > > >>>> ----- Original Message ----- > >>>>>>>> > > >>>>> From: "Michael Pasternak" > >>>>>>>> > > >>>>> To: "Libor Spevak" > >>>>>>>> > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > >>>>>>>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > >>>>>>>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from > >>>>>>>> > > >>>>> the GUI > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Hi Libor, > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> This issue came across in one of the conversations > >>>>>>>> > > >>>>> i had with > >>>>>>>> > > >>>>> UX > >>>>>>>> > > >>>>> folks, but since we didn't end > >>>>>>>> > > >>>>> up with any conclusion/road map (nor discussed it > >>>>>>>> > > >>>>> properly to > >>>>>>>> > > >>>>> hear > >>>>>>>> > > >>>>> other thoughts), this is a perfect > >>>>>>>> > > >>>>> place to start this discussion, > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX > >>>>>>>> > > >>>>> calls > >>>>>>>> > > >>>>> --------------------------------------------------- > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> pros > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - api data objects can be reused by generating > >>>>>>>> > > >>>>> java classes > >>>>>>>> > > >>>>> (using > >>>>>>>> > > >>>>> jaxb) from the rest schema [1] > >>>>>>>> > > >>>>> - no backend logic will be duplicated as api > >>>>>>>> > > >>>>> abstracts the > >>>>>>>> > > >>>>> backend > >>>>>>>> > > >>>>> exposing RESTful collection/resources to operate > >>>>>>>> > > >>>>> on > >>>>>>>> > > >>>>> - development against api is "easy" as api > >>>>>>>> > > >>>>> describes itself > >>>>>>>> > > >>>>> in > >>>>>>>> > > >>>>> RSDL > >>>>>>>> > > >>>>> [2] > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> cons > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - implementing transport layer (HTTP) under GWT > >>>>>>>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling > >>>>>>>> > > >>>>> layer > >>>>>>>> > > >>>>> - implementing own error handling mechanism > >>>>>>>> > > >>>>> - implementing REST callback mechanism (in GWT) > >>>>>>>> > > >>>>> - constant maintenance of the data objects > >>>>>>>> > > >>>>> generated from the > >>>>>>>> > > >>>>> api > >>>>>>>> > > >>>>> - painful for Java developers > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Java-SDK > >>>>>>>> > > >>>>> -------- > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> pros > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - abstracts transport layer (leaving developer in > >>>>>>>> > > >>>>> standard > >>>>>>>> > > >>>>> Java > >>>>>>>> > > >>>>> api) > >>>>>>>> > > >>>>> - typesafe code (no need to mess with XML bulks) > >>>>>>>> > > >>>>> - has own data objects to work with > >>>>>>>> > > >>>>> - abstracts authentication/authorization > >>>>>>>> > > >>>>> (kerberos/cookie/session/etc.) > >>>>>>>> > > >>>>> - since SDK is auto-generated, it can be easily > >>>>>>>> > > >>>>> extended with > >>>>>>>> > > >>>>> required > >>>>>>>> > > >>>>> features to support UI (such as callback > >>>>>>>> > > >>>>> infrastructure for > >>>>>>>> > > >>>>> instance) > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> cons > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - has to be converted in to Javascript (not sure > >>>>>>>> > > >>>>> what the > >>>>>>>> > > >>>>> impacts > >>>>>>>> > > >>>>> are > >>>>>>>> > > >>>>> in terms of AJAX calls/etc.) > >>>>>>>> > > >>>>> - probably much more cons that we're not aware of > >>>>>>>> > > >>>>> and will > >>>>>>>> > > >>>>> have > >>>>>>>> > > >>>>> to > >>>>>>>> > > >>>>> figure out with POC > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> thoughts? > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema > >>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl > >>>>>>>> > > >>>>> > >>>>>>> > > >>>> > >>>>>>> > > >>>> Although started as a UI request, there are other > >>>>>>> > > >>>> needs who > >>>>>>> > > >>>> wish > >>>>>>> > > >>>> to use API calls with a different transport. For > >>>>>>> > > >>>> example a > >>>>>>> > > >>>> backend > >>>>>>> > > >>>> hook which gets a REST entry point it can use to > >>>>>>> > > >>>> fetch for > >>>>>>> > > >>>> additional > >>>>>>> > > >>>> data, or perform actions. In this case I'd expect an > >>>>>>> > > >>>> internal > >>>>>>> > > >>>> connection > >>>>>>> > > >>>> rather than creating additional connections. > >>>>>>> > > >>>> How would you resolve it generically enough in this > >>>>>>> > > >>>> context? > >>>>>> > > >>> > >>>>>> > > >>> Doron, > >>>>>> > > >>> > >>>>>> > > >>> I believe your approach a bit different, UX folks > >>>>>> > > >>> seeking for a > >>>>>> > > >>> convenient > >>>>>> > > >>> way of communicating with ovirt public api, e.g > >>>>>> > > >>> closing > >>>>>> > > >>> api<->GUI > >>>>>> > > >>> gap, and > >>>>>> > > >>> theirs alternatives where native HTTP layer or > >>>>>> > > >>> Java-SDK based > >>>>>> > > >>> framework, > >>>>>> > > >>> while what you need is in-process channel to > >>>>>> > > >>> communicate with > >>>>>> > > >>> the > >>>>>> > > >>> engine itself, > >>>>>> > > >>> > >>>>>> > > >>> i understanding your will of using stable api for this > >>>>>> > > >>> (RESTapi), > >>>>>> > > >>> but > >>>>>> > > >>> not > >>>>>> > > >>> sure that doing this via JavaSDK is a good way to go > >>>>>> > > >>> simply > >>>>>> > > >>> because > >>>>>> > > >>> SDK is > >>>>>> > > >>> designed to operate in a client-space, while what you > >>>>>> > > >>> need is a > >>>>>> > > >>> server-space > >>>>>> > > >>> bridge for that. > >>>>>> > > >>> > >>>>> > > >> > >>>>> > > >> Michael, true but... > >>>>> > > >> Thinking about it differently both UI and hooks needs a > >>>>> > > >> client. > >>>>> > > >> The underlying protocols should be abstracted. This is > >>>>> > > >> something > >>>>> > > >> which will serve other functions as well. > >>>>> > > >> > >>>> > > > > >>>> > > > I'm not sure we would need a new abstraction here. > >>>> > > > Both UI plugins and engine plugins need some API to do > >>>> > > > basic > >>>> > > > operations, and have access to different properties in the > >>>> > > > engine. > >>> > > > >>> > > +1, that's exactly what i've suggested to begin with. > >>> > > > >> > > >> > The only issue is that UI plugins and engine plugins shave > >> > different > >> > expectations > >> > from performance point of view. If UI is willing to wait for a > >> > refresh that may > >> > take too long for engine plugins, which would prefer to get the > >> > information as > >> > soon as possible without going into various communication layers > >> > which are not > >> > always needed. So again- a simple solution which enables > >> > transports > >> > layers to > >> > be replaced may serve more than one functionality in a better > >> > way. > >> > > > Let's start with the simple solution. We don't know yet who will > > the plugins, how would they be used, and whether using the SDK > > will be a bottleneck of any kind. If the proposed solution is to > > support different transport layers while still using the SDK, then > > it is an extension we can always do in the future, if we find it > > of high benefit. > > (btw, regardless of that, the API/SDK is now faster than in the > > past, as we support REST sessions, which removes the need to > > re-authenticate upon each API request). > > > > true, but the real bottleneck is sending XML bulks over the wire + > bi-directional marshalling X 2 (engine<->api + api<->xml). > Here we're in agreement. From dfediuck at redhat.com Mon Feb 25 13:24:31 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 25 Feb 2013 08:24:31 -0500 (EST) Subject: [Engine-devel] REST API calls from In-Reply-To: <1605013790.7186572.1361743009535.JavaMail.root@redhat.com> Message-ID: <1627541299.8876315.1361798671082.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Oved Ourfalli" > To: "Doron Fediuck" > Cc: engine-devel at ovirt.org, arch at ovirt.org > Sent: Sunday, February 24, 2013 11:56:49 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Oved Ourfalli" > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > Sent: Sunday, February 24, 2013 3:55:28 PM > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > ----- Original Message ----- > > > From: "Oved Ourfalli" > > > To: "Doron Fediuck" > > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > > Sent: Sunday, February 24, 2013 3:01:19 PM > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Doron Fediuck" > > > > To: "Michael Pasternak" > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org, > > > > arch at ovirt.org > > > > Sent: Sunday, February 24, 2013 1:20:12 PM > > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Michael Pasternak" > > > > > To: "Oved Ourfalli" > > > > > Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > > Sent: Sunday, February 24, 2013 9:47:28 AM > > > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > >> From: "Doron Fediuck" > > > > > >> To: "Michael Pasternak" > > > > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > > > > >> Subject: Re: [Engine-devel] REST API calls from > > > > > >> > > > > > >> > > > > > >> > > > > > >> ----- Original Message ----- > > > > > >>> From: "Michael Pasternak" > > > > > >>> To: "Doron Fediuck" > > > > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > > > > >>> Subject: Re: [Engine-devel] REST API calls from > > > > > >>> > > > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > > >>>> > > > > > >>>> > > > > > >>>> ----- Original Message ----- > > > > > >>>>> From: "Michael Pasternak" > > > > > >>>>> To: "Libor Spevak" > > > > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org > > > > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > > > > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> Hi Libor, > > > > > >>>>> > > > > > >>>>> This issue came across in one of the conversations i > > > > > >>>>> had > > > > > >>>>> with > > > > > >>>>> UX > > > > > >>>>> folks, but since we didn't end > > > > > >>>>> up with any conclusion/road map (nor discussed it > > > > > >>>>> properly > > > > > >>>>> to > > > > > >>>>> hear > > > > > >>>>> other thoughts), this is a perfect > > > > > >>>>> place to start this discussion, > > > > > >>>>> > > > > > >>>>> Intuitively REST is a way to go with GWT AJAX calls > > > > > >>>>> --------------------------------------------------- > > > > > >>>>> > > > > > >>>>> pros > > > > > >>>>> ==== > > > > > >>>>> > > > > > >>>>> - api data objects can be reused by generating java > > > > > >>>>> classes > > > > > >>>>> (using > > > > > >>>>> jaxb) from the rest schema [1] > > > > > >>>>> - no backend logic will be duplicated as api abstracts > > > > > >>>>> the > > > > > >>>>> backend > > > > > >>>>> exposing RESTful collection/resources to operate on > > > > > >>>>> - development against api is "easy" as api describes > > > > > >>>>> itself > > > > > >>>>> in > > > > > >>>>> RSDL > > > > > >>>>> [2] > > > > > >>>>> > > > > > >>>>> cons > > > > > >>>>> ==== > > > > > >>>>> > > > > > >>>>> - implementing transport layer (HTTP) under GWT > > > > > >>>>> - implementing own j2xml/json/yaml/... marshalling > > > > > >>>>> layer > > > > > >>>>> - implementing own error handling mechanism > > > > > >>>>> - implementing REST callback mechanism (in GWT) > > > > > >>>>> - constant maintenance of the data objects generated > > > > > >>>>> from > > > > > >>>>> the > > > > > >>>>> api > > > > > >>>>> - painful for Java developers > > > > > >>>>> > > > > > >>>>> Java-SDK > > > > > >>>>> -------- > > > > > >>>>> > > > > > >>>>> pros > > > > > >>>>> ==== > > > > > >>>>> > > > > > >>>>> - abstracts transport layer (leaving developer in > > > > > >>>>> standard > > > > > >>>>> Java > > > > > >>>>> api) > > > > > >>>>> - typesafe code (no need to mess with XML bulks) > > > > > >>>>> - has own data objects to work with > > > > > >>>>> - abstracts authentication/authorization > > > > > >>>>> (kerberos/cookie/session/etc.) > > > > > >>>>> - since SDK is auto-generated, it can be easily > > > > > >>>>> extended > > > > > >>>>> with > > > > > >>>>> required > > > > > >>>>> features to support UI (such as callback > > > > > >>>>> infrastructure > > > > > >>>>> for > > > > > >>>>> instance) > > > > > >>>>> > > > > > >>>>> cons > > > > > >>>>> ==== > > > > > >>>>> > > > > > >>>>> - has to be converted in to Javascript (not sure what > > > > > >>>>> the > > > > > >>>>> impacts > > > > > >>>>> are > > > > > >>>>> in terms of AJAX calls/etc.) > > > > > >>>>> - probably much more cons that we're not aware of and > > > > > >>>>> will > > > > > >>>>> have > > > > > >>>>> to > > > > > >>>>> figure out with POC > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> thoughts? > > > > > >>>>> > > > > > >>>>> [1] http[s]://server[:port]/api?schema > > > > > >>>>> [2] http[s]://server[:port]/api?rsdl > > > > > >>>>> > > > > > >>>> > > > > > >>>> Although started as a UI request, there are other needs > > > > > >>>> who > > > > > >>>> wish > > > > > >>>> to use API calls with a different transport. For example > > > > > >>>> a > > > > > >>>> backend > > > > > >>>> hook which gets a REST entry point it can use to fetch > > > > > >>>> for > > > > > >>>> additional > > > > > >>>> data, or perform actions. In this case I'd expect an > > > > > >>>> internal > > > > > >>>> connection > > > > > >>>> rather than creating additional connections. > > > > > >>>> How would you resolve it generically enough in this > > > > > >>>> context? > > > > > >>> > > > > > >>> Doron, > > > > > >>> > > > > > >>> I believe your approach a bit different, UX folks seeking > > > > > >>> for > > > > > >>> a > > > > > >>> convenient > > > > > >>> way of communicating with ovirt public api, e.g closing > > > > > >>> api<->GUI > > > > > >>> gap, and > > > > > >>> theirs alternatives where native HTTP layer or Java-SDK > > > > > >>> based > > > > > >>> framework, > > > > > >>> while what you need is in-process channel to communicate > > > > > >>> with > > > > > >>> the > > > > > >>> engine itself, > > > > > >>> > > > > > >>> i understanding your will of using stable api for this > > > > > >>> (RESTapi), > > > > > >>> but > > > > > >>> not > > > > > >>> sure that doing this via JavaSDK is a good way to go > > > > > >>> simply > > > > > >>> because > > > > > >>> SDK is > > > > > >>> designed to operate in a client-space, while what you > > > > > >>> need > > > > > >>> is > > > > > >>> a > > > > > >>> server-space > > > > > >>> bridge for that. > > > > > >>> > > > > > >> > > > > > >> Michael, true but... > > > > > >> Thinking about it differently both UI and hooks needs a > > > > > >> client. > > > > > >> The underlying protocols should be abstracted. This is > > > > > >> something > > > > > >> which will serve other functions as well. > > > > > >> > > > > > > > > > > > > I'm not sure we would need a new abstraction here. > > > > > > Both UI plugins and engine plugins need some API to do > > > > > > basic > > > > > > operations, and have access to different properties in the > > > > > > engine. > > > > > > > > > > +1, that's exactly what i've suggested to begin with. > > > > > > > > > > > > > The only issue is that UI plugins and engine plugins shave > > > > different > > > > expectations > > > > from performance point of view. If UI is willing to wait for a > > > > refresh that may > > > > take too long for engine plugins, which would prefer to get the > > > > information as > > > > soon as possible without going into various communication > > > > layers > > > > which are not > > > > always needed. So again- a simple solution which enables > > > > transports > > > > layers to > > > > be replaced may serve more than one functionality in a better > > > > way. > > > > > > > > > > Let's start with the simple solution. We don't know yet who will > > > the > > > plugins, how would they be used, and whether using the SDK will > > > be > > > a > > > bottleneck of any kind. If the proposed solution is to support > > > different transport layers while still using the SDK, then it is > > > an > > > extension we can always do in the future, if we find it of high > > > benefit. > > > (btw, regardless of that, the API/SDK is now faster than in the > > > past, > > > as we support REST sessions, which removes the need to > > > re-authenticate upon each API request). > > > > > > > Oved, we have pretty good idea on how it will be used and what will > > create performance hits. Otherwise we wouldn't have had this > > thread. > > > If so, it would be nice if you share this information on the thread > as well... some use-cases, some statistics you may have on the > current performance, and on the performance requirements, and etc. > I'm not saying that you're wrong... just saying I wasn't convinced it > is really necessary. > > Thank you, > Oved Think of intensive calls to an external scheduling 'hook'. We had a few threads about it in the past, and there's a wiki (being reworked now). Since you can never anticipate the information that hook will need, we should allow it to use REST API to fetch the information it needs from the backend. As Michael already answered opening a client in that hook will not be the optimal solution if it needs to open TCP connections. > > > > > > In the UI plguins implementation, we gave this API, and in > > > > > > addition > > > > > > created a REST session to be used in order to do more > > > > > > sophisticated operations. > > > > > > I think we should probably do the same for engine plugins, > > > > > > giving the basic API, and giving a REST session for more > > > > > > advanced > > > > > > operations. > > > > > > The engine plugin may also have another 3rd party > > > > > > application > > > > > > it > > > > > > interacts with, and it would be able to share this session > > > > > > with > > > > > > it, > > > > > > allowing it to perform different operations on the engine. > > > > > > It > > > > > > would > > > > > > obviously be easy to do that using the Java SDK in the > > > > > > engine > > > > > > side, > > > > > > without creating a new layer of abstraction. > > > > > > > > > > true, but the thing is that java-sdk designed to work with > > > > > rest-api, > > > > > and what Doron is trying to do > > > > > is saving round-trip of engine->sdk->api->engine by enabling > > > > > extra > > > > > layer in sdk that will work not via HTTP, > > > > > but natively with RESTeasy (REST framework we using in api), > > > > > the > > > > > disadvantages of such design are: > > > > > > > > > > 1. working with java-sdk via JNI (walking out from container > > > > > to > > > > > client application - sdk) > > > > > 2. hacking RESTeasy by: > > > > > 2.1 working with underlying (not public/backward > > > > > compatible) > > > > > interfaces & using JNI as well > > > > > 2.2 most likely maintaining code working with RESTeasy on > > > > > every > > > > > new (RESTeasy) release by reverse > > > > > engineering new changes/behaviour of this framework > > > > > 2.3 making assumptions on code invocations to emulate > > > > > GET/POST/PUT/DELETE HTTP calls > > > > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > > > > > > > therefore i think that having own private API in engine for > > > > > that > > > > > is > > > > > a > > > > > much better solution. > > > > > > > > > > > I assume the 3rd party application will use either the Java > > > > > > SDK, > > > > > > or > > > > > > another one, according the platform it is built upon, and > > > > > > in > > > > > > the > > > > > > "worst case", will interact directly with the API. > > > > > > > > > > > > > > > > > >>>> > > > > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: > > > > > >>>>>> Hi, > > > > > >>>>>> > > > > > >>>>>> I would like to ask, if there have been discussions > > > > > >>>>>> about > > > > > >>>>>> an > > > > > >>>>>> option > > > > > >>>>>> to call REST API services directly from the Frontend > > > > > >>>>>> (GWT > > > > > >>>>>> layer)? > > > > > >>>>>> GWT compiles Java frontend-side to > > > > > >>>>>> Javascript, calls to backend services are performed > > > > > >>>>>> "transparently" > > > > > >>>>>> by the framework using AJAX support. But, there is > > > > > >>>>>> still > > > > > >>>>>> a > > > > > >>>>>> need > > > > > >>>>>> to > > > > > >>>>>> have a special set of data objects > > > > > >>>>>> and the server-side logic can duplicate. > > > > > >>>>>> > > > > > >>>>>> Java REST API SDK enables to build "thick" client. The > > > > > >>>>>> calls > > > > > >>>>>> are > > > > > >>>>>> realized using e.g. Apache HttClient and supported > > > > > >>>>>> libraries. > > > > > >>>>>> I > > > > > >>>>>> think the requirements of GWT can be a > > > > > >>>>>> little bit different, but something overlaps. > > > > > >>>>>> > > > > > >>>>>> I found several links about REST API support from GWT, > > > > > >>>>>> so > > > > > >>>>>> there > > > > > >>>>>> is > > > > > >>>>>> something for inspiration... > > > > > >>>>>> > > > > > >>>>>> - http://www.spiffyui.org/ > > > > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ > > > > > >>>>>> - http://code.google.com/p/gwt-rest/ > > > > > >>>>>> - http://restygwt.fusesource.org/ > > > > > >>>>>> > > > > > >>>>>> But, do you think it would be useful and what > > > > > >>>>>> drawbacks > > > > > >>>>>> can > > > > > >>>>>> occur > > > > > >>>>>> (authentication, authorization, response times, need > > > > > >>>>>> to > > > > > >>>>>> support > > > > > >>>>>> larger set of services, painful > > > > > >>>>>> refactoring, ...)? > > > > > >>>>>> > > > > > >>>>>> Regards, > > > > > >>>>>> Libor > > > > > >>>>>> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From rydekull at gmail.com Mon Feb 25 14:32:24 2013 From: rydekull at gmail.com (Alexander Rydekull) Date: Mon, 25 Feb 2013 15:32:24 +0100 Subject: RPM-builds for CentOS Message-ID: Hello all, I am one of the members of the oVirt Infrastructure team. We have, as you might know some servers that have been sponsored which we plan to deploy. As the selection of our OS, we've chosen to go with CentOS 6. We plan to install oVirt on these machines, but there are no packages available for CentOS, from us, as of today. To be a bit more precise, we're looking for a repo, just like the one below, but for CentOS 6: http://resources.ovirt.org/releases/3.2/rpm/Fedora/17/ The reason I'm sending this mail is to ask if someone would be willing to package it for CentOS 6. Preferably the people that already package it for Fedora. I might point out that I've heard there might be some progress on this already, and if it is, please forgive my ignorance for missing out on it. But if you have more information, do let me know, since we are very eager to get the nodes up and running. Thank you. -- /Alexander Rydekull -------------- next part -------------- An HTML attachment was scrubbed... URL: From danken at redhat.com Mon Feb 25 15:04:50 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 25 Feb 2013 17:04:50 +0200 Subject: RPM-builds for CentOS In-Reply-To: References: Message-ID: <20130225150450.GJ11422@redhat.com> On Mon, Feb 25, 2013 at 03:32:24PM +0100, Alexander Rydekull wrote: > Hello all, > > I am one of the members of the oVirt Infrastructure team. We have, as you > might know some servers that have been sponsored which we plan to deploy. > As the selection of our OS, we've chosen to go with CentOS 6. > > We plan to install oVirt on these machines, but there are no packages > available for CentOS, from us, as of today. > > To be a bit more precise, we're looking for a repo, just like the one > below, but for CentOS 6: > http://resources.ovirt.org/releases/3.2/rpm/Fedora/17/ > > The reason I'm sending this mail is to ask if someone would be willing to > package it for CentOS 6. > Preferably the people that already package it for Fedora. > > I might point out that I've heard there might be some progress on this > already, and if it is, please forgive my ignorance for missing out on it. > But if you have more information, do let me know, since we are very eager > to get the nodes up and running. +1 for this request from me. Whomever voluteers to take responsibility on the el6 build should remember that a moder python-pep8 (such as http://danken.fedorapeople.org/python-pep8-1.3.3-3.el6.noarch.rpm ) is required for the build. From mgoldboi at redhat.com Mon Feb 25 15:21:54 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Mon, 25 Feb 2013 17:21:54 +0200 Subject: RPM-builds for CentOS In-Reply-To: References: Message-ID: <512B8192.5030800@redhat.com> On 02/25/2013 04:32 PM, Alexander Rydekull wrote: > Hello all, > > I am one of the members of the oVirt Infrastructure team. We have, as > you might know some servers that have been sponsored which we plan to > deploy. As the selection of our OS, we've chosen to go with CentOS 6. > > We plan to install oVirt on these machines, but there are no packages > available for CentOS, from us, as of today. > > To be a bit more precise, we're looking for a repo, just like the one > below, but for CentOS 6: > http://resources.ovirt.org/releases/3.2/rpm/Fedora/17/ > > The reason I'm sending this mail is to ask if someone would be willing > to package it for CentOS 6. > Preferably the people that already package it for Fedora. > > I might point out that I've heard there might be some progress on this > already, and if it is, please forgive my ignorance for missing out on > it. But if you have more information, do let me know, since we are > very eager to get the nodes up and running. > > Thank you. > > -- > /Alexander Rydekull > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch This is work in progress, adding Ofer and Juan to shade some light on the status from engine side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Feb 26 13:32:16 2013 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 26 Feb 2013 13:32:16 +0000 Subject: RPM-builds for CentOS Message-ID: <512CB960.3010401@karan.org> Hi Guys, Is what we have here of any use ? http://dev.centos.org/centos/6/ovirt/ There are atleast a few hundred people hitting that repo. Happy to collaborate and bring the resulting product across to the CentOS userbase. Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From iheim at redhat.com Tue Feb 26 13:46:38 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 26 Feb 2013 15:46:38 +0200 Subject: RPM-builds for CentOS In-Reply-To: <512CB960.3010401@karan.org> References: <512CB960.3010401@karan.org> Message-ID: <512CBCBE.1020603@redhat.com> On 26/02/2013 15:32, Karanbir Singh wrote: > Hi Guys, > > Is what we have here of any use ? > > http://dev.centos.org/centos/6/ovirt/ > > There are at least a few hundred people hitting that repo. Happy to > collaborate and bring the resulting product across to the CentOS userbase. > > Regards > we are actively working on creating .el6 rpms for ovirt 3.2 and will be happy to collaborate. Thanks, Itamar From johnny at centos.org Tue Feb 26 14:41:53 2013 From: johnny at centos.org (Johnny Hughes) Date: Tue, 26 Feb 2013 08:41:53 -0600 Subject: CentOS 6 repo for oVirt Message-ID: <512CC9B1.9020500@centos.org> All, My name is Johnny Hughes and I am one of the CentOS Developers. I currently maintain the testing CentOS-6 oVirt repository that Karanbir pointed to: http://dev.centos.org/centos/6/ovirt/ There are other things that need to be maintained besides just python-pep8. Also needing to be maintained is a version of jboss, maven, jpackage, and several other python rpms. The above repo is maintained from this git repo: https://nazar.karan.org/?team=ovirt I am just getting ready to make this work with the oVirt 3.2 release. There is also this wiki page: http://wiki.centos.org/HowTos/oVirt We would love to have oVirt as an official CentOS offering and would be glad to add members of this list to maintain our current repo and help us move it from testing to production. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From alonbl at redhat.com Tue Feb 26 15:02:43 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 26 Feb 2013 10:02:43 -0500 (EST) Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <1361179401.13448.54.camel@dhcp-29-7.brq.redhat.com> Message-ID: <526429322.3590653.1361890963857.JavaMail.root@redhat.com> ----- Original Message ----- > From: "David Ja?a" > To: vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Monday, February 18, 2013 11:23:21 AM > Subject: Re: [vdsm] vdsm networking changes proposal > > Hi, > > Alon Bar-Lev p??e v Ne 17. 02. 2013 v 15:57 -0500: > > Hello Antoni, > > > > Great work! > > I am very excited we are going this route, it is first of many to > > allow us to be run on different distributions. > > I apologize I got to this so late. > > > > Notes for the model, I am unsure if someone already noted. > > > > I think that the abstraction should be more than entity and > > properties. > > > > For example: > > > > nic is a network interface > > bridge is a network interface and ports network interfaces > > bound is a network interface and slave network interfaces > > vlan is a network interface and vlan id > > > > network interface can have: > > - name > > - ip config > > - state > > - mtu > > > > this way it would be easier to share common code that handle pure > > interfaces. > > > > I don't quite understand the 'Team' configurator, are you > > suggesting a provider for each technology? > > Team is a new implementation of bonding in Linux kernel IIRC. > > > > > bridge > > - iproute2 provider > > - ovs provider > > - ifcfg provider > > > > bond > > - iproute2 > > - team > > - ovs > > - ifcfg > > > > vlan > > - iproute2 > > - ovs > > - ifcfg > > > > So we can get a configuration of: > > bridge:iproute2 > > bond:team > > vlan:ovs > > > > ? > > > > I also would like us to explore a future alternative of the network > > configuration via crypto vpn directly from qemu to another qemu, > > the idea is to have a kerberos like key per layer3(or layer2) > > destination, while communication is encrypted at user space and > > sent to a flat network. The advantage of this is that we manage > > logical network and not physical network, while relaying on > > hardware to find the best route to destination. The question is > > how and if we can provide this via the suggestion abstraction. But > > maybe it is too soon to address this kind of future. > > Isn't it better to separate the two goals and persuade qemu > developers to implement TLS for migration connections? Sure :) But someone/something will need to configure it... :) > > > > > For the open questions: > > > > 1. Yes, I think that mode should be non-persistence, persistence > > providers should emulate non-persistence operations by diff > > between what they have and the goal. > > > > 2. Once vdsm is installed, the mode it runs should be fixed. So the > > only question is what is the selected profile during host > > deployment. > > > > 3. I think that if we can avoid aliases it would be nice. > > > > 4. Keeping the least persistence information would be flexible. I > > would love to see a zero persistence mode available, for example > > if management interface is dhcp or manually configured. > > > > I am very fond of the iproute2 configuration, and don't mind if > > administrator configures the management interface manually. I > > think this can supersede the ifcfg quite easily in most cases. In > > these rare cases administrator use ovirt to modify the network > > interface we may consider delegating persistence to totally > > different model. But as far as I understand the problem is solely > > related to the management connectivity, so we can implement a > > simple bootstrap of non-persistence module to reconstruct the > > management network setup from vdsm configuration instead of > > persisting it to the distribution width configuration. > > > > Regards, > > Alon Bar-Lev > > > > ----- Original Message ----- > > > From: "Antoni Segura Puimedon" > > > To: arch at ovirt.org, vdsm-devel at fedorahosted.org > > > Sent: Friday, February 8, 2013 12:54:23 AM > > > Subject: vdsm networking changes proposal > > > > > > Hi fellow oVirters! > > > > > > The network team and a few others have toyed in the past with > > > several > > > important > > > changes like using open vSwitch, talking D-BUS to NM, making the > > > network > > > non-persistent, etc. > > > > > > It is with some of this changes in mind that we (special thanks > > > go to > > > Livnat > > > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal > > > for > > > a new architecture for vdsm's networking part. This proposal is > > > intended to > > > make our software more adaptable to new components and use cases, > > > eliminate > > > distro dependancies as much as possible and improve the > > > responsiveness and > > > scalability of the networking operations. > > > > > > To do so, it proposes an object oriented representation of the > > > different > > > elements that come into play in our networking use cases. > > > > > > But enough of introduction, please go to the feature page that we > > > have put > > > together and help us with your feedback, questions proposals and > > > extensions. > > > > > > http://www.ovirt.org/Feature/NetworkReloaded > > > > > > > > > Best regards, > > > > > > Toni > > > _______________________________________________ > > > Arch mailing list > > > Arch at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel at lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From alonbl at redhat.com Tue Feb 26 15:11:46 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 26 Feb 2013 10:11:46 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <20130225103446.GC11422@redhat.com> Message-ID: <1521874195.3592816.1361891506736.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Monday, February 25, 2013 12:34:46 PM > Subject: Re: vdsm networking changes proposal > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > Hello Antoni, > > > > Great work! > > I am very excited we are going this route, it is first of many to > > allow us to be run on different distributions. > > I apologize I got to this so late. > > > > Notes for the model, I am unsure if someone already noted. > > > > I think that the abstraction should be more than entity and > > properties. > > > > For example: > > > > nic is a network interface > > bridge is a network interface and ports network interfaces > > bound is a network interface and slave network interfaces > > vlan is a network interface and vlan id > > > > network interface can have: > > - name > > - ip config > > - state > > - mtu > > > > this way it would be easier to share common code that handle pure > > interfaces. > > I agree with you - even though OOD is falling out of fashion in > certain > circles. If we develop software like dressing fashion, we end up with software working for a single season. > > > > > I don't quite understand the 'Team' configurator, are you > > suggesting a > > provider for each technology? > > Just as we may decide to move away from standard linux bridge to > ovs-based bridging, we may switch from bonding to teaming. I do not > think that we should do it now, but make sure that the design > accomodates this. So there should a separate provider for each object type, unless I am missing something. > > > > bridge > > - iproute2 provider > > - ovs provider > > - ifcfg provider > > > > bond > > - iproute2 > > - team > > - ovs > > - ifcfg > > > > vlan > > - iproute2 > > - ovs > > - ifcfg > > > > So we can get a configuration of: > > bridge:iproute2 > > bond:team > > vlan:ovs > > I do not think that such complex combinations are of real interest. > The > client should not (currently) be allowed to request them. Some say > that > the specific combination that is used by Vdsm to implement the > network > should be defined in a config file. I think that a python file is > good > enough for that, at least for now. I completely lost you, and how it got to do with python nor file. If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? If we register provider per object type we may allow easier reuse. This, however, does not imply that the implementation is in python (oh well...) nor if the implementation is single file or multiple file... > > > > ? > > > > I also would like us to explore a future alternative of the network > > configuration via crypto vpn directly from qemu to another qemu, > > the > > idea is to have a kerberos like key per layer3(or layer2) > > destination, > > while communication is encrypted at user space and sent to a flat > > network. The advantage of this is that we manage logical network > > and > > not physical network, while relaying on hardware to find the best > > route to destination. The question is how and if we can provide > > this > > via the suggestion abstraction. But maybe it is too soon to address > > this kind of future. > > This is something completely different, as we say in Python. > The nice thing about your idea, is that in the context of host > network > configuration we need nothing more than our current bridge-bond-nic. > The sad thing about your idea, is that it would scale badly with the > nubmer of virtual networks. If a new VM comes live and sends an ARP > who-has broadcast message - which VMs should be bothered to attempt > to > decrypt it? This is easily filtered by a tag. Just like in MPLS. > > > > > For the open questions: > > > > 1. Yes, I think that mode should be non-persistence, persistence > > providers should emulate non-persistence operations by diff > > between what they have and the goal. > > > > 2. Once vdsm is installed, the mode it runs should be fixed. So the > > only question is what is the selected profile during host > > deployment. > > > > 3. I think that if we can avoid aliases it would be nice. > > I wonder if everybody agrees that aliases are not needed. > > > > > 4. Keeping the least persistence information would be flexible. I > > would love to see a zero persistence mode available, for example if > > management interface is dhcp or manually configured. > > > > I am very fond of the iproute2 configuration, and don't mind if > > administrator configures the management interface manually. I think > > this can supersede the ifcfg quite easily in most cases. In these > > rare > > cases administrator use ovirt to modify the network interface we > > may > > consider delegating persistence to totally different model. But as > > far > > as I understand the problem is solely related to the management > > connectivity, so we can implement a simple bootstrap of > > non-persistence module to reconstruct the management network setup > > from vdsm configuration instead of persisting it to the > > distribution > > width configuration. > > > > Regards, > > Alon Bar-Lev > > Thanks, > Dan. > From alonbl at redhat.com Tue Feb 26 15:20:25 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 26 Feb 2013 10:20:25 -0500 (EST) Subject: [vdsm] vdsm networking changes proposal In-Reply-To: <20130225104919.GD11422@redhat.com> Message-ID: <1628709003.3595974.1361892025808.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Mark Wu" > Cc: arch at ovirt.org, vdsm-devel at fedorahosted.org > Sent: Monday, February 25, 2013 12:49:19 PM > Subject: Re: [vdsm] vdsm networking changes proposal > > On Thu, Feb 21, 2013 at 05:55:45PM +0800, Mark Wu wrote: > > On Thu 21 Feb 2013 04:46:16 PM CST, Mark Wu wrote: > > >On 02/18/2013 05:23 PM, David Ja?a wrote: > > > > Sorry for coming to it so late. > > Happy new year! > > > I get the following comments and questions about the proposal. > > > > I suggest to add a field of top interface to the network, and only > > apply IpConfig and mtu to it. > > I'm not sure how such an added field would help. Isn't the info > already > available within the stucture of interface objects? Or do you suggest > a > read-only field? I'd appreciate more details. > > > > > For the openvswitch configurator, it needs assistance of iproute2 > > because it can't configure ip/netmask/gw and mtu. > > Thanks, added to wiki. > > > > > I can't figure out the point to allow different configurators > > except > > openvswitch coexist. It could cause unnecessary complexity. > > I agree that we should decide on a very limited set of valid > configurator combinations. > > > > > In the proposal, the rollback mechanism can be used to persist > > configuration for iproute2. Why do we still need NetworkManager? > > We may need NetworkManager. It is present and running by default on > our > target platforms -- inlcuding my laptop -- and it can be a bit rude > to > other services that try to configure network devices not through it. Maybe the reason to have NetworkManager provider is for pure debug/development purposes, so you can run it on your laptop. I think that as go forward we [might] see that the considerations for hypervisors out-ways these of the desktop distribution. > > > > > I think the solution of "iproute2 + openvswitch + serializing > > configuration objects" can meet all our requirements. I remember > > that Dan had a concern of > > adding a new standard about it in previous discussion. Have we > > already get agreement on it? > > Well, I'd say that I've caved in. I see no other way forward without > introducing our own form of persisting network definitions. At least > we > keep our current setupNetworks API for that. > > Dan. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From danken at redhat.com Tue Feb 26 15:45:50 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 26 Feb 2013 17:45:50 +0200 Subject: vdsm networking changes proposal In-Reply-To: <1521874195.3592816.1361891506736.JavaMail.root@redhat.com> References: <20130225103446.GC11422@redhat.com> <1521874195.3592816.1361891506736.JavaMail.root@redhat.com> Message-ID: <20130226154550.GS11422@redhat.com> On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Alon Bar-Lev" > > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > > Sent: Monday, February 25, 2013 12:34:46 PM > > Subject: Re: vdsm networking changes proposal > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > > Hello Antoni, > > > > > > Great work! > > > I am very excited we are going this route, it is first of many to > > > allow us to be run on different distributions. > > > I apologize I got to this so late. > > > > > > Notes for the model, I am unsure if someone already noted. > > > > > > I think that the abstraction should be more than entity and > > > properties. > > > > > > For example: > > > > > > nic is a network interface > > > bridge is a network interface and ports network interfaces > > > bound is a network interface and slave network interfaces > > > vlan is a network interface and vlan id > > > > > > network interface can have: > > > - name > > > - ip config > > > - state > > > - mtu > > > > > > this way it would be easier to share common code that handle pure > > > interfaces. > > > > I agree with you - even though OOD is falling out of fashion in > > certain > > circles. > > If we develop software like dressing fashion, we end up with software working for a single season. > > > > > > > > > I don't quite understand the 'Team' configurator, are you > > > suggesting a > > > provider for each technology? > > > > Just as we may decide to move away from standard linux bridge to > > ovs-based bridging, we may switch from bonding to teaming. I do not > > think that we should do it now, but make sure that the design > > accomodates this. > > So there should a separate provider for each object type, unless I am missing something. > > > > > > > bridge > > > - iproute2 provider > > > - ovs provider > > > - ifcfg provider > > > > > > bond > > > - iproute2 > > > - team > > > - ovs > > > - ifcfg > > > > > > vlan > > > - iproute2 > > > - ovs > > > - ifcfg > > > > > > So we can get a configuration of: > > > bridge:iproute2 > > > bond:team > > > vlan:ovs > > > > I do not think that such complex combinations are of real interest. > > The > > client should not (currently) be allowed to request them. Some say > > that > > the specific combination that is used by Vdsm to implement the > > network > > should be defined in a config file. I think that a python file is > > good > > enough for that, at least for now. > > I completely lost you, and how it got to do with python nor file. > > If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? > > If we register provider per object type we may allow easier reuse. Yes, this is the plan. However I do not think it is wise to support all conceivable combinations of provider/object. A fixed one, such as "ovs for bridge and vlan, iproute2 for bond" is good enough. > > This, however, does not imply that the implementation is in python (oh > well...) nor if the implementation is single file or multiple file... > > > > > > > ? > > > > > > I also would like us to explore a future alternative of the network > > > configuration via crypto vpn directly from qemu to another qemu, > > > the > > > idea is to have a kerberos like key per layer3(or layer2) > > > destination, > > > while communication is encrypted at user space and sent to a flat > > > network. The advantage of this is that we manage logical network > > > and > > > not physical network, while relaying on hardware to find the best > > > route to destination. The question is how and if we can provide > > > this > > > via the suggestion abstraction. But maybe it is too soon to address > > > this kind of future. > > > > This is something completely different, as we say in Python. > > The nice thing about your idea, is that in the context of host > > network > > configuration we need nothing more than our current bridge-bond-nic. > > The sad thing about your idea, is that it would scale badly with the > > nubmer of virtual networks. If a new VM comes live and sends an ARP > > who-has broadcast message - which VMs should be bothered to attempt > > to > > decrypt it? > > This is easily filtered by a tag. Just like in MPLS. How is it different from a vlan tag, then? Or that you suggest that we trust qemu to do the tagging, instead of the host kernel? From alonbl at redhat.com Tue Feb 26 15:51:12 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 26 Feb 2013 10:51:12 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <20130226154550.GS11422@redhat.com> Message-ID: <1222104595.3608080.1361893872307.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Tuesday, February 26, 2013 5:45:50 PM > Subject: Re: vdsm networking changes proposal > > On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > > From: "Dan Kenigsberg" > > > To: "Alon Bar-Lev" > > > Cc: "Antoni Segura Puimedon" , > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > Sent: Monday, February 25, 2013 12:34:46 PM > > > Subject: Re: vdsm networking changes proposal > > > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > > > Hello Antoni, > > > > > > > > Great work! > > > > I am very excited we are going this route, it is first of many > > > > to > > > > allow us to be run on different distributions. > > > > I apologize I got to this so late. > > > > > > > > Notes for the model, I am unsure if someone already noted. > > > > > > > > I think that the abstraction should be more than entity and > > > > properties. > > > > > > > > For example: > > > > > > > > nic is a network interface > > > > bridge is a network interface and ports network interfaces > > > > bound is a network interface and slave network interfaces > > > > vlan is a network interface and vlan id > > > > > > > > network interface can have: > > > > - name > > > > - ip config > > > > - state > > > > - mtu > > > > > > > > this way it would be easier to share common code that handle > > > > pure > > > > interfaces. > > > > > > I agree with you - even though OOD is falling out of fashion in > > > certain > > > circles. > > > > If we develop software like dressing fashion, we end up with > > software working for a single season. > > > > > > > > > > > > > I don't quite understand the 'Team' configurator, are you > > > > suggesting a > > > > provider for each technology? > > > > > > Just as we may decide to move away from standard linux bridge to > > > ovs-based bridging, we may switch from bonding to teaming. I do > > > not > > > think that we should do it now, but make sure that the design > > > accomodates this. > > > > So there should a separate provider for each object type, unless I > > am missing something. > > > > > > > > > > bridge > > > > - iproute2 provider > > > > - ovs provider > > > > - ifcfg provider > > > > > > > > bond > > > > - iproute2 > > > > - team > > > > - ovs > > > > - ifcfg > > > > > > > > vlan > > > > - iproute2 > > > > - ovs > > > > - ifcfg > > > > > > > > So we can get a configuration of: > > > > bridge:iproute2 > > > > bond:team > > > > vlan:ovs > > > > > > I do not think that such complex combinations are of real > > > interest. > > > The > > > client should not (currently) be allowed to request them. Some > > > say > > > that > > > the specific combination that is used by Vdsm to implement the > > > network > > > should be defined in a config file. I think that a python file is > > > good > > > enough for that, at least for now. > > > > I completely lost you, and how it got to do with python nor file. > > > > If we have implementation of iproute2 that does bridge, vlan, bond, > > but we like to use ovs for bridge and vlan, how can we reuse the > > iproute2 provider for the bond? > > > > If we register provider per object type we may allow easier reuse. > > Yes, this is the plan. However I do not think it is wise to support > all > conceivable combinations of provider/object. A fixed one, such as > "ovs > for bridge and vlan, iproute2 for bond" is good enough. The whole point of the abstraction/provider thing is to vdsm *NOT* be aware of the underline technologies. I would not like to see 'if ovs then' or any other similar one in vdsm code after we have this mechanism in place. Not that I say that a total generic sequence will require to work, but the ovs for bridge and vlan should be compatible with iproute for bond, while iproute for bridge and iproute for vlan and iproute for bond are compatible as well. > > > > This, however, does not imply that the implementation is in python > > (oh > > well...) nor if the implementation is single file or multiple > > file... > > > > > > > > > > > ? > > > > > > > > I also would like us to explore a future alternative of the > > > > network > > > > configuration via crypto vpn directly from qemu to another > > > > qemu, > > > > the > > > > idea is to have a kerberos like key per layer3(or layer2) > > > > destination, > > > > while communication is encrypted at user space and sent to a > > > > flat > > > > network. The advantage of this is that we manage logical > > > > network > > > > and > > > > not physical network, while relaying on hardware to find the > > > > best > > > > route to destination. The question is how and if we can provide > > > > this > > > > via the suggestion abstraction. But maybe it is too soon to > > > > address > > > > this kind of future. > > > > > > This is something completely different, as we say in Python. > > > The nice thing about your idea, is that in the context of host > > > network > > > configuration we need nothing more than our current > > > bridge-bond-nic. > > > The sad thing about your idea, is that it would scale badly with > > > the > > > nubmer of virtual networks. If a new VM comes live and sends an > > > ARP > > > who-has broadcast message - which VMs should be bothered to > > > attempt > > > to > > > decrypt it? > > > > This is easily filtered by a tag. Just like in MPLS. > > How is it different from a vlan tag, then? Or that you suggest that > we > trust qemu to do the tagging, instead of the host kernel? I think that like MPLS, there will be vlan emulation server that qemu will register into. But I think I am way ahead of this specific discussion. Alon From danken at redhat.com Wed Feb 27 09:14:35 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 27 Feb 2013 11:14:35 +0200 Subject: vdsm networking changes proposal In-Reply-To: <1222104595.3608080.1361893872307.JavaMail.root@redhat.com> References: <20130226154550.GS11422@redhat.com> <1222104595.3608080.1361893872307.JavaMail.root@redhat.com> Message-ID: <20130227091435.GB24789@redhat.com> On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Alon Bar-Lev" > > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > > Sent: Tuesday, February 26, 2013 5:45:50 PM > > Subject: Re: vdsm networking changes proposal > > > > On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Dan Kenigsberg" > > > > To: "Alon Bar-Lev" > > > > Cc: "Antoni Segura Puimedon" , > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > Sent: Monday, February 25, 2013 12:34:46 PM > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > > > > Hello Antoni, > > > > > > > > > > Great work! > > > > > I am very excited we are going this route, it is first of many > > > > > to > > > > > allow us to be run on different distributions. > > > > > I apologize I got to this so late. > > > > > > > > > > Notes for the model, I am unsure if someone already noted. > > > > > > > > > > I think that the abstraction should be more than entity and > > > > > properties. > > > > > > > > > > For example: > > > > > > > > > > nic is a network interface > > > > > bridge is a network interface and ports network interfaces > > > > > bound is a network interface and slave network interfaces > > > > > vlan is a network interface and vlan id > > > > > > > > > > network interface can have: > > > > > - name > > > > > - ip config > > > > > - state > > > > > - mtu > > > > > > > > > > this way it would be easier to share common code that handle > > > > > pure > > > > > interfaces. > > > > > > > > I agree with you - even though OOD is falling out of fashion in > > > > certain > > > > circles. > > > > > > If we develop software like dressing fashion, we end up with > > > software working for a single season. > > > > > > > > > > > > > > > > > I don't quite understand the 'Team' configurator, are you > > > > > suggesting a > > > > > provider for each technology? > > > > > > > > Just as we may decide to move away from standard linux bridge to > > > > ovs-based bridging, we may switch from bonding to teaming. I do > > > > not > > > > think that we should do it now, but make sure that the design > > > > accomodates this. > > > > > > So there should a separate provider for each object type, unless I > > > am missing something. > > > > > > > > > > > > > bridge > > > > > - iproute2 provider > > > > > - ovs provider > > > > > - ifcfg provider > > > > > > > > > > bond > > > > > - iproute2 > > > > > - team > > > > > - ovs > > > > > - ifcfg > > > > > > > > > > vlan > > > > > - iproute2 > > > > > - ovs > > > > > - ifcfg > > > > > > > > > > So we can get a configuration of: > > > > > bridge:iproute2 > > > > > bond:team > > > > > vlan:ovs > > > > > > > > I do not think that such complex combinations are of real > > > > interest. > > > > The > > > > client should not (currently) be allowed to request them. Some > > > > say > > > > that > > > > the specific combination that is used by Vdsm to implement the > > > > network > > > > should be defined in a config file. I think that a python file is > > > > good > > > > enough for that, at least for now. > > > > > > I completely lost you, and how it got to do with python nor file. > > > > > > If we have implementation of iproute2 that does bridge, vlan, bond, > > > but we like to use ovs for bridge and vlan, how can we reuse the > > > iproute2 provider for the bond? > > > > > > If we register provider per object type we may allow easier reuse. > > > > Yes, this is the plan. However I do not think it is wise to support > > all > > conceivable combinations of provider/object. A fixed one, such as > > "ovs > > for bridge and vlan, iproute2 for bond" is good enough. > > The whole point of the abstraction/provider thing is to vdsm *NOT* be > aware of the underline technologies. I would not like to see 'if ovs > then' or any other similar one in vdsm code after we have this > mechanism in place. Vdsm has to be aware of the underlying technologies, but this awareness has to be confined to two places: - the providers. - the thing that selects which provider should be used today. > > Not that I say that a total generic sequence will require to work, but > the ovs for bridge and vlan should be compatible with iproute for > bond, while iproute for bridge and iproute for vlan and iproute for > bond are compatible as well. Sure. Dan. From alonbl at redhat.com Wed Feb 27 11:06:30 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 27 Feb 2013 06:06:30 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <20130227091435.GB24789@redhat.com> Message-ID: <181320794.3865362.1361963190928.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Wednesday, February 27, 2013 11:14:35 AM > Subject: Re: vdsm networking changes proposal > > On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > > From: "Dan Kenigsberg" > > > To: "Alon Bar-Lev" > > > Cc: "Antoni Segura Puimedon" , > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > Sent: Tuesday, February 26, 2013 5:45:50 PM > > > Subject: Re: vdsm networking changes proposal > > > > > > On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Dan Kenigsberg" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Antoni Segura Puimedon" , > > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > > Sent: Monday, February 25, 2013 12:34:46 PM > > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > > > > > Hello Antoni, > > > > > > > > > > > > Great work! > > > > > > I am very excited we are going this route, it is first of > > > > > > many > > > > > > to > > > > > > allow us to be run on different distributions. > > > > > > I apologize I got to this so late. > > > > > > > > > > > > Notes for the model, I am unsure if someone already noted. > > > > > > > > > > > > I think that the abstraction should be more than entity and > > > > > > properties. > > > > > > > > > > > > For example: > > > > > > > > > > > > nic is a network interface > > > > > > bridge is a network interface and ports network interfaces > > > > > > bound is a network interface and slave network interfaces > > > > > > vlan is a network interface and vlan id > > > > > > > > > > > > network interface can have: > > > > > > - name > > > > > > - ip config > > > > > > - state > > > > > > - mtu > > > > > > > > > > > > this way it would be easier to share common code that > > > > > > handle > > > > > > pure > > > > > > interfaces. > > > > > > > > > > I agree with you - even though OOD is falling out of fashion > > > > > in > > > > > certain > > > > > circles. > > > > > > > > If we develop software like dressing fashion, we end up with > > > > software working for a single season. > > > > > > > > > > > > > > > > > > > > > I don't quite understand the 'Team' configurator, are you > > > > > > suggesting a > > > > > > provider for each technology? > > > > > > > > > > Just as we may decide to move away from standard linux bridge > > > > > to > > > > > ovs-based bridging, we may switch from bonding to teaming. I > > > > > do > > > > > not > > > > > think that we should do it now, but make sure that the design > > > > > accomodates this. > > > > > > > > So there should a separate provider for each object type, > > > > unless I > > > > am missing something. > > > > > > > > > > > > > > > > bridge > > > > > > - iproute2 provider > > > > > > - ovs provider > > > > > > - ifcfg provider > > > > > > > > > > > > bond > > > > > > - iproute2 > > > > > > - team > > > > > > - ovs > > > > > > - ifcfg > > > > > > > > > > > > vlan > > > > > > - iproute2 > > > > > > - ovs > > > > > > - ifcfg > > > > > > > > > > > > So we can get a configuration of: > > > > > > bridge:iproute2 > > > > > > bond:team > > > > > > vlan:ovs > > > > > > > > > > I do not think that such complex combinations are of real > > > > > interest. > > > > > The > > > > > client should not (currently) be allowed to request them. > > > > > Some > > > > > say > > > > > that > > > > > the specific combination that is used by Vdsm to implement > > > > > the > > > > > network > > > > > should be defined in a config file. I think that a python > > > > > file is > > > > > good > > > > > enough for that, at least for now. > > > > > > > > I completely lost you, and how it got to do with python nor > > > > file. > > > > > > > > If we have implementation of iproute2 that does bridge, vlan, > > > > bond, > > > > but we like to use ovs for bridge and vlan, how can we reuse > > > > the > > > > iproute2 provider for the bond? > > > > > > > > If we register provider per object type we may allow easier > > > > reuse. > > > > > > Yes, this is the plan. However I do not think it is wise to > > > support > > > all > > > conceivable combinations of provider/object. A fixed one, such as > > > "ovs > > > for bridge and vlan, iproute2 for bond" is good enough. > > > > The whole point of the abstraction/provider thing is to vdsm *NOT* > > be > > aware of the underline technologies. I would not like to see 'if > > ovs > > then' or any other similar one in vdsm code after we have this > > mechanism in place. > > Vdsm has to be aware of the underlying technologies, but this > awareness > has to be confined to two places: > - the providers. > - the thing that selects which provider should be used today. I don't understand the 2nd item... why is 'today' important? and what is 'thing'? > > > > > Not that I say that a total generic sequence will require to work, > > but > > the ovs for bridge and vlan should be compatible with iproute for > > bond, while iproute for bridge and iproute for vlan and iproute for > > bond are compatible as well. > > Sure. > > Dan. > From danken at redhat.com Wed Feb 27 12:02:48 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 27 Feb 2013 14:02:48 +0200 Subject: vdsm networking changes proposal In-Reply-To: <181320794.3865362.1361963190928.JavaMail.root@redhat.com> References: <20130227091435.GB24789@redhat.com> <181320794.3865362.1361963190928.JavaMail.root@redhat.com> Message-ID: <20130227120248.GL24789@redhat.com> On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Alon Bar-Lev" > > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > > Sent: Wednesday, February 27, 2013 11:14:35 AM > > Subject: Re: vdsm networking changes proposal > > > > On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Dan Kenigsberg" > > > > To: "Alon Bar-Lev" > > > > Cc: "Antoni Segura Puimedon" , > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > Sent: Tuesday, February 26, 2013 5:45:50 PM > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dan Kenigsberg" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "Antoni Segura Puimedon" , > > > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > > > Sent: Monday, February 25, 2013 12:34:46 PM > > > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: > > > > > > > Hello Antoni, > > > > > > > > > > > > > > Great work! > > > > > > > I am very excited we are going this route, it is first of > > > > > > > many > > > > > > > to > > > > > > > allow us to be run on different distributions. > > > > > > > I apologize I got to this so late. > > > > > > > > > > > > > > Notes for the model, I am unsure if someone already noted. > > > > > > > > > > > > > > I think that the abstraction should be more than entity and > > > > > > > properties. > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > nic is a network interface > > > > > > > bridge is a network interface and ports network interfaces > > > > > > > bound is a network interface and slave network interfaces > > > > > > > vlan is a network interface and vlan id > > > > > > > > > > > > > > network interface can have: > > > > > > > - name > > > > > > > - ip config > > > > > > > - state > > > > > > > - mtu > > > > > > > > > > > > > > this way it would be easier to share common code that > > > > > > > handle > > > > > > > pure > > > > > > > interfaces. > > > > > > > > > > > > I agree with you - even though OOD is falling out of fashion > > > > > > in > > > > > > certain > > > > > > circles. > > > > > > > > > > If we develop software like dressing fashion, we end up with > > > > > software working for a single season. > > > > > > > > > > > > > > > > > > > > > > > > > I don't quite understand the 'Team' configurator, are you > > > > > > > suggesting a > > > > > > > provider for each technology? > > > > > > > > > > > > Just as we may decide to move away from standard linux bridge > > > > > > to > > > > > > ovs-based bridging, we may switch from bonding to teaming. I > > > > > > do > > > > > > not > > > > > > think that we should do it now, but make sure that the design > > > > > > accomodates this. > > > > > > > > > > So there should a separate provider for each object type, > > > > > unless I > > > > > am missing something. > > > > > > > > > > > > > > > > > > > bridge > > > > > > > - iproute2 provider > > > > > > > - ovs provider > > > > > > > - ifcfg provider > > > > > > > > > > > > > > bond > > > > > > > - iproute2 > > > > > > > - team > > > > > > > - ovs > > > > > > > - ifcfg > > > > > > > > > > > > > > vlan > > > > > > > - iproute2 > > > > > > > - ovs > > > > > > > - ifcfg > > > > > > > > > > > > > > So we can get a configuration of: > > > > > > > bridge:iproute2 > > > > > > > bond:team > > > > > > > vlan:ovs > > > > > > > > > > > > I do not think that such complex combinations are of real > > > > > > interest. > > > > > > The > > > > > > client should not (currently) be allowed to request them. > > > > > > Some > > > > > > say > > > > > > that > > > > > > the specific combination that is used by Vdsm to implement > > > > > > the > > > > > > network > > > > > > should be defined in a config file. I think that a python > > > > > > file is > > > > > > good > > > > > > enough for that, at least for now. > > > > > > > > > > I completely lost you, and how it got to do with python nor > > > > > file. > > > > > > > > > > If we have implementation of iproute2 that does bridge, vlan, > > > > > bond, > > > > > but we like to use ovs for bridge and vlan, how can we reuse > > > > > the > > > > > iproute2 provider for the bond? > > > > > > > > > > If we register provider per object type we may allow easier > > > > > reuse. > > > > > > > > Yes, this is the plan. However I do not think it is wise to > > > > support > > > > all > > > > conceivable combinations of provider/object. A fixed one, such as > > > > "ovs > > > > for bridge and vlan, iproute2 for bond" is good enough. > > > > > > The whole point of the abstraction/provider thing is to vdsm *NOT* > > > be > > > aware of the underline technologies. I would not like to see 'if > > > ovs > > > then' or any other similar one in vdsm code after we have this > > > mechanism in place. > > > > Vdsm has to be aware of the underlying technologies, but this > > awareness > > has to be confined to two places: > > - the providers. > > - the thing that selects which provider should be used today. > > I don't understand the 2nd item... why is 'today' important? and what is 'thing'? It's not really difficult, nor important, but let me try again. Assume we have code of two providers for bridge. One is ifcfg-based, the other is ovs-based. That's item 1. Now we get a command to create a bridge. We do not intend to change the API to let Engine select which of the two providers should be used, so it is vdsm's obligation. That's item 2. From alonbl at redhat.com Wed Feb 27 14:22:10 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 27 Feb 2013 09:22:10 -0500 (EST) Subject: vdsm networking changes proposal In-Reply-To: <20130227120248.GL24789@redhat.com> Message-ID: <776074265.3903855.1361974930182.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Wednesday, February 27, 2013 2:02:48 PM > Subject: Re: vdsm networking changes proposal > > On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > > From: "Dan Kenigsberg" > > > To: "Alon Bar-Lev" > > > Cc: "Antoni Segura Puimedon" , > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > Sent: Wednesday, February 27, 2013 11:14:35 AM > > > Subject: Re: vdsm networking changes proposal > > > > > > On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Dan Kenigsberg" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Antoni Segura Puimedon" , > > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > > Sent: Tuesday, February 26, 2013 5:45:50 PM > > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > > > On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Dan Kenigsberg" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "Antoni Segura Puimedon" , > > > > > > > vdsm-devel at fedorahosted.org, arch at ovirt.org > > > > > > > Sent: Monday, February 25, 2013 12:34:46 PM > > > > > > > Subject: Re: vdsm networking changes proposal > > > > > > > > > > > > > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev > > > > > > > wrote: > > > > > > > > Hello Antoni, > > > > > > > > > > > > > > > > Great work! > > > > > > > > I am very excited we are going this route, it is first > > > > > > > > of > > > > > > > > many > > > > > > > > to > > > > > > > > allow us to be run on different distributions. > > > > > > > > I apologize I got to this so late. > > > > > > > > > > > > > > > > Notes for the model, I am unsure if someone already > > > > > > > > noted. > > > > > > > > > > > > > > > > I think that the abstraction should be more than entity > > > > > > > > and > > > > > > > > properties. > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > nic is a network interface > > > > > > > > bridge is a network interface and ports network > > > > > > > > interfaces > > > > > > > > bound is a network interface and slave network > > > > > > > > interfaces > > > > > > > > vlan is a network interface and vlan id > > > > > > > > > > > > > > > > network interface can have: > > > > > > > > - name > > > > > > > > - ip config > > > > > > > > - state > > > > > > > > - mtu > > > > > > > > > > > > > > > > this way it would be easier to share common code that > > > > > > > > handle > > > > > > > > pure > > > > > > > > interfaces. > > > > > > > > > > > > > > I agree with you - even though OOD is falling out of > > > > > > > fashion > > > > > > > in > > > > > > > certain > > > > > > > circles. > > > > > > > > > > > > If we develop software like dressing fashion, we end up > > > > > > with > > > > > > software working for a single season. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't quite understand the 'Team' configurator, are > > > > > > > > you > > > > > > > > suggesting a > > > > > > > > provider for each technology? > > > > > > > > > > > > > > Just as we may decide to move away from standard linux > > > > > > > bridge > > > > > > > to > > > > > > > ovs-based bridging, we may switch from bonding to > > > > > > > teaming. I > > > > > > > do > > > > > > > not > > > > > > > think that we should do it now, but make sure that the > > > > > > > design > > > > > > > accomodates this. > > > > > > > > > > > > So there should a separate provider for each object type, > > > > > > unless I > > > > > > am missing something. > > > > > > > > > > > > > > > > > > > > > > bridge > > > > > > > > - iproute2 provider > > > > > > > > - ovs provider > > > > > > > > - ifcfg provider > > > > > > > > > > > > > > > > bond > > > > > > > > - iproute2 > > > > > > > > - team > > > > > > > > - ovs > > > > > > > > - ifcfg > > > > > > > > > > > > > > > > vlan > > > > > > > > - iproute2 > > > > > > > > - ovs > > > > > > > > - ifcfg > > > > > > > > > > > > > > > > So we can get a configuration of: > > > > > > > > bridge:iproute2 > > > > > > > > bond:team > > > > > > > > vlan:ovs > > > > > > > > > > > > > > I do not think that such complex combinations are of real > > > > > > > interest. > > > > > > > The > > > > > > > client should not (currently) be allowed to request them. > > > > > > > Some > > > > > > > say > > > > > > > that > > > > > > > the specific combination that is used by Vdsm to > > > > > > > implement > > > > > > > the > > > > > > > network > > > > > > > should be defined in a config file. I think that a python > > > > > > > file is > > > > > > > good > > > > > > > enough for that, at least for now. > > > > > > > > > > > > I completely lost you, and how it got to do with python nor > > > > > > file. > > > > > > > > > > > > If we have implementation of iproute2 that does bridge, > > > > > > vlan, > > > > > > bond, > > > > > > but we like to use ovs for bridge and vlan, how can we > > > > > > reuse > > > > > > the > > > > > > iproute2 provider for the bond? > > > > > > > > > > > > If we register provider per object type we may allow easier > > > > > > reuse. > > > > > > > > > > Yes, this is the plan. However I do not think it is wise to > > > > > support > > > > > all > > > > > conceivable combinations of provider/object. A fixed one, > > > > > such as > > > > > "ovs > > > > > for bridge and vlan, iproute2 for bond" is good enough. > > > > > > > > The whole point of the abstraction/provider thing is to vdsm > > > > *NOT* > > > > be > > > > aware of the underline technologies. I would not like to see > > > > 'if > > > > ovs > > > > then' or any other similar one in vdsm code after we have this > > > > mechanism in place. > > > > > > Vdsm has to be aware of the underlying technologies, but this > > > awareness > > > has to be confined to two places: > > > - the providers. > > > - the thing that selects which provider should be used today. > > > > I don't understand the 2nd item... why is 'today' important? and > > what is 'thing'? > > It's not really difficult, nor important, but let me try again. > > Assume we have code of two providers for bridge. One is ifcfg-based, > the > other is ovs-based. That's item 1. > > Now we get a command to create a bridge. We do not intend to change > the > API to let Engine select which of the two providers should be used, > so > it is vdsm's obligation. That's item 2. > I think that the settings of which provider to use for what technology is to be specified via configuration, vdsm should not hard code anything regarding specific provider behavior, technology or other. The obligation of having a sane configuration is on the administrator (or the host-deploy automation). This approach will ensure will will be able to support multiple configurations without releasing new versions of vdsm, or be able to support different provider layout per distribution or usage (development/production). If vdsm is to be aware of specific provider behavior, this behavior should be exposed at the provider's interface. Alon From snmishra at linux.vnet.ibm.com Wed Feb 27 20:34:47 2013 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Wed, 27 Feb 2013 12:34:47 -0800 Subject: Backup Restore API integration feature page available. Message-ID: <20130227123447.Horde.PxC8Lpir309RLm3np2CXcTA@imap.linux.ibm.com> Hi, Please take a look at the feature page and provide feedback. This is still a work in progress and more details will be added as we make progress. http://www.ovirt.org/Features/Backup-Restore_API_Integration Thanks Sharad Mishra From iheim at redhat.com Wed Feb 27 21:49:00 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 27 Feb 2013 23:49:00 +0200 Subject: CentOS 6 repo for oVirt In-Reply-To: <512CC9B1.9020500@centos.org> References: <512CC9B1.9020500@centos.org> Message-ID: <512E7F4C.4050604@redhat.com> On 26/02/2013 16:41, Johnny Hughes wrote: > All, > > My name is Johnny Hughes and I am one of the CentOS Developers. > > I currently maintain the testing CentOS-6 oVirt repository that Karanbir > pointed to: > > http://dev.centos.org/centos/6/ovirt/ > > There are other things that need to be maintained besides just > python-pep8. Also needing to be maintained is a version of jboss, > maven, jpackage, and several other python rpms. > > The above repo is maintained from this git repo: > > https://nazar.karan.org/?team=ovirt > > I am just getting ready to make this work with the oVirt 3.2 release. > > There is also this wiki page: > > http://wiki.centos.org/HowTos/oVirt > > We would love to have oVirt as an official CentOS offering and would be > glad to add members of this list to maintain our current repo and help > us move it from testing to production. > we are working on making the ovirt repo compatible with .el6 "out of the box", and probably generate nightly .el6 rpms like we do for fedora today. so hopefully other than the various deps you've mentioned, gap for the distro should be minimal. From rocky.craig at hp.com Thu Feb 28 01:11:00 2013 From: rocky.craig at hp.com (Rocky Craig) Date: Wed, 27 Feb 2013 18:11:00 -0700 Subject: CentOS 6 repo for oVirt In-Reply-To: <512CC9B1.9020500@centos.org> References: <512CC9B1.9020500@centos.org> Message-ID: <512EAEA4.2020908@hp.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5063 bytes Desc: S/MIME Cryptographic Signature URL: From iheim at redhat.com Thu Feb 28 15:10:30 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 28 Feb 2013 17:10:30 +0200 Subject: Backup Restore API integration feature page available. In-Reply-To: <20130227123447.Horde.PxC8Lpir309RLm3np2CXcTA@imap.linux.ibm.com> References: <20130227123447.Horde.PxC8Lpir309RLm3np2CXcTA@imap.linux.ibm.com> Message-ID: <512F7366.2040907@redhat.com> On 27/02/2013 22:34, snmishra at linux.vnet.ibm.com wrote: > Hi, > > Please take a look at the feature page and provide feedback. This is > still a work in progress and more details will be added as we make > progress. > > http://www.ovirt.org/Features/Backup-Restore_API_Integration > > Thanks > Sharad Mishra > would be great to close this gap. a few questions: - do we differentiate between the backup snapshots and the regular snapshots? i.e., can user see them? delete them? revert to a snapshot before them? what happens if they go stale since backup process failed/broke - can admin intervene and clean them up? - in 'prepare backup disk', there is a lock disk phase. when is the lock released? which operations are blocked by this lock? - the flow seems to be directed at a running guest ('live snapshot') - what happens if the guest to be backed up isn't currently running? - i'm missing a bit more details on the exact flow, as it happens on each component. -- on which node is the nbd launched / consumed -- where does the backup agent/appliance run (same node as the ndb one?) Thanks, Itamar From johnny at centos.org Thu Feb 28 19:53:51 2013 From: johnny at centos.org (Johnny Hughes) Date: Thu, 28 Feb 2013 13:53:51 -0600 Subject: CentOS 6 repo for oVirt In-Reply-To: <512EAEA4.2020908@hp.com> References: <512CC9B1.9020500@centos.org> <512EAEA4.2020908@hp.com> Message-ID: <512FB5CF.9040602@centos.org> On 02/27/2013 07:11 PM, Rocky Craig wrote: > Johnny, > > A few days ago you said > > > I currently maintain the testing CentOS-6 oVirt repository..... > > I am just getting ready to make this work with the oVirt 3.2 release. > > Can you divulge a little more precision on your time frame? > > I've just spent a lot of February getting ovirt-engine to build > and run on CentOS 6.2 with OpenJDK 1.6. My approach was > similar to that for (your) oVirt 3.1 work. > > If your timeframe is "soon" (like March), I'd rather put my > efforts aside and wait for a more sanctioned release done > by people who know what they're doing :-) Soon is basically going to be the first thing after CentOS-6.4 is released and past the initial early problem stages. So, some time in mid March to begin is certainly possible. I have not completely decided yet as I have to research requirements, but my initial inclination is to build everything that will do so with OpenJDK 1.7 .. including items being pulled in from the OS. I know OpenJDK 1.6 will continue to get support from Red Hat, but Oracle is stopping support for Java 6, so moving to OpenJDK 1.7 seems like a good move to me. Some of the system packages will only build with java-1.5.0-gcj, but for things that build with and use JDK, using 1.7.0 (so 3 versions are not needed) will be the goal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: