We''re happy to announce XenMaster, which has the ambitious goal to become the de facto frontend for Xen with XCP. We''ve had the opportunity to present our project to some of the Xen/XCP developers and now it''s time to announce the project to a larger public. XenMaster, in short, is a HTML5 frontend coupled to a Java backend delivering a rich UI for Xen, targeted at end users. At the moment, one is able to successfully add NFS ISO repositories and iSCSI/NFS storage repositories (iSCSI currently only works on XenServer 5.6), create a HVM VM and control it via a VNC shell. Development thus far has been carried out by Jorgen Evens, frontend lead and Wannes De Smet, project lead and backend developer. Of course, we now would like to welcome you in becoming a tester and/or contributor! You can find more information at xen-master.org, to install and configure XenMaster. If you''d like to help and have experience in developing Java and/or Javascript, load the source in your favorite IDE and have at it! If you have any questions at all, we''ll be happy to answer them here or through GitHub. We hope to welcome you in using XenMaster! Jorgen Evens Wannes De Smet XenMaster _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
We''re happy to announce XenMaster, which has the ambitious goal to become the de facto frontend for Xen with XCP. We''ve had the opportunity to present our project to some of the Xen/XCP developers and now it''s time to announce the project to a larger public. XenMaster, in short, is a HTML5 frontend coupled to a Java backend delivering a rich UI for Xen, targeted at end users. At the moment, one is able to successfully add NFS ISO repositories and iSCSI/NFS storage repositories (iSCSI currently only works on XenServer 5.6), create a HVM VM and control it via a VNC shell. Development thus far has been carried out by Jorgen Evens, frontend lead and Wannes De Smet, project lead and backend developer. Of course, we now would like to welcome you in becoming a tester and/or contributor! You can find more information at xen-master.org, to install and configure XenMaster. If you''d like to help and have experience in developing Java and/or Javascript, load the source in your favorite IDE and have at it! If you have any questions at all, we''ll be happy to answer them here or through GitHub. We hope to welcome you in using XenMaster! Jorgen Evens Wannes De Smet XenMaster
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Wannes De Smet <wannes321@gmail.com> schrieb:>We''re happy to announce XenMaster, which has the ambitious goal to >become the de facto frontend for Xen with XCP.This sounds very nice... ...but sorry, why do you use a richfat and plumby Java backend? There are a lot of smaller, ressource efficient, incomplex and easier to handle open source technologies - even full oo - available to build such a HTML management front- and even backend? best regards, Niels. - -- Niels Dettenbach Syndicat IT&Internet http://www.syndicat.com -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iIEEAREIAEEFAk82xKg6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDR60AJ95aO+TB7Zn sn2sP9cVR8MSTvwEPQCeO0GemEeFPm+QNSk19s1Fxd8QgEo=T1wf -----END PGP SIGNATURE-----
On 11 Feb 2012, at 20:42, Niels Dettenbach (Syndicat IT&Internet) wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > > > Wannes De Smet <wannes321@gmail.com> schrieb: > >> We''re happy to announce XenMaster, which has the ambitious goal to >> become the de facto frontend for Xen with XCP. > > This sounds very nice…Thank you> > ...but sorry, why do you use a richfat and plumby Java backend? There are a lot of smaller, ressource efficient, incomplex and easier to handle open source technologies - even full oo - available to build such a HTML management front- and even backend? >We agree that in comparison to xm/xl/xe, running a Java stack might seem to be a bit on the heavy side. Yet we''d like to note that our back-end is nothing like Tomcat or Glassfish, it contains only the bare minimum needed to do its work. To elaborate choosing Java for our back-end: - Java applications can be deployed on a wide variety of operating systems, if not all. - Eventually the back-end will also be orchestrating pools or clusters. - The back-end parses responses and shrinks updates down to only the bare minimum, limiting bandwidth use by the front-end. - The back-end allows access to your servers over a single TCP/IP port, the Xen-API will not be publicly exposed. - Again we’re not running a whole Java EE stack, the front-end is a webapp that lives on its own and communicates with the backend over a WebSocket connection. - Coupled with Cassandra, the back-end is the only thing that needs to be run (one single instance), for any number of hosts.> > best regards, > > > Niels. > - -- > Niels Dettenbach > Syndicat IT&Internet > http://www.syndicat.com > -----BEGIN PGP SIGNATURE----- > Version: APG v1.0.8 > > iIEEAREIAEEFAk82xKg6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu > dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDR60AJ95aO+TB7Zn > sn2sP9cVR8MSTvwEPQCeO0GemEeFPm+QNSk19s1Fxd8QgEo> =T1wf > -----END PGP SIGNATURE----- >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 12 Feb 2012, at 01:03, George Shuklin wrote:> >>> >>> ...but sorry, why do you use a richfat and plumby Java backend? There are a lot of smaller, ressource efficient, incomplex and easier to handle open source technologies - even full oo - available to build such a HTML management front- and even backend? >>> >> We agree that in comparison to >> xm/xl/xe, running a Java stack might seem to be a bit on >> the heavy side. Yet we''d like to note that our back-end is >> nothing like Tomcat or Glassfish, it contains only the >> bare minimum needed to do its work. >> >> To >> elaborate choosing Java for our back-end: >> - Java >> applications can be deployed on a wide variety of >> operating systems, if not all. >> - >> Eventually the back-end will also be orchestrating pools >> or clusters. >> - The >> back-end parses responses and shrinks updates down to only >> the bare minimum, limiting bandwidth use by the front-end. >> - The >> back-end allows access to your servers over a single >> TCP/IP port, the Xen-API will not be publicly exposed. >> - Again >> we’re not running a whole Java EE stack, the front-end is >> a webapp that lives on its own and communicates with the >> backend over a WebSocket connection. >> - >> Coupled with Cassandra, the back-end is the only thing >> that needs to be run (one single instance), for any number >> of hosts. >> >> >> > > I''m very against Java. After Oracle license change sun-jre package was forced to be removed from the most distros. Right now Oracle does not properly supports any dpkg (deb) based Linux distrubition, providing only RPMs and some creepy tarball. This actually means ''very bad linux support''. And if we looks how Oracle do business we can see no future for nice multiplatform support. Yes, there is open-source implementation for JRE, but it still uncomplete, and, again, resistance to publish opensource code for certification is looking ugly.Oracle didn''t make a very good first impression in FOSS land, that''s true. But there are a few things you should know about the Java situation in relation to Oracle: - The OpenJDK project now carries the reference implementation for Java, adapted by Oracle for use in their own products. So one can safely assume it''s quite complete and well-tested. - Sure the community maintained builds might not be Oracle supported, but I''d argue that isn''t much of a necessity anyway; even for production. The open source builds run just fine (I''m talking about my experience here). - The TCK license allows running the JCK for the OpenJDK code.> > So using a ''half-opened'' open-source solution, where specification is controlled by not-very-opensource-friendly company for new open-source product is really bad idea. >The specification is controlled by the Executive Committee (http://jcp.org/en/participation/committee). Sure, Oracle might be a major influence, but saying they integrally control the specification is wrong. And, by all means, cut Oracle some slack, their attitude towards open-source was and still is improving.> > HTML5 is much more open standard, so using html5 is more proper solution. > > ... OK, let''s forget Linux. Looks at windows. IE will supports HTML5 out of box. And future is looking promising. And how about Java? Yes, you need to download it, install is separately, it starts to nagging about updates, and it does not supports for windows system updates, so you need to update it manually. Again, comparation Java VS HTML5 is not toward Java. > >It''s not one versus the other, it''s HTML5 working together with a Java backend (rather lovely, I might add). W> _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 12, 2012 at 8:03 AM, George Shuklin <george.shuklin@gmail.com>wrote:> > > ...but sorry, why do you use a richfat and plumby Java backend? There are > a lot of smaller, ressource efficient, incomplex and easier to handle open > source technologies - even full oo - available to build such a HTML > management front- and even backend? > > *We agree that in comparison to xm/xl/xe, running a Java stack might > seem to be a bit on the heavy side. Yet we''d like to note that our back-end > is nothing like Tomcat or Glassfish, it contains only the bare minimum > needed to do its work. > > To elaborate choosing Java for our back-end: > - Java applications can be deployed on a wide variety of operating > systems, if not all. > - Eventually the back-end will also be orchestrating pools or clusters. > - The back-end parses responses and shrinks updates down to only the bare > minimum, limiting bandwidth use by the front-end. > - The back-end allows access to your servers over a single TCP/IP port, > the Xen-API will not be publicly exposed. > - Again we’re not running a whole Java EE stack, the front-end is a webapp > that lives on its own and communicates with the backend over a WebSocket > connection. > - Coupled with Cassandra, the back-end is the only thing that needs to be > run (one single instance), for any number of hosts. > * > > > I''m very against Java. After Oracle license change sun-jre package was > forced to be removed from the most distros. Right now Oracle does not > properly supports any dpkg (deb) based Linux distrubition, providing only > RPMs and some creepy tarball. This actually means ''very bad linux support''. > And if we looks how Oracle do business we can see no future for nice > multiplatform support. Yes, there is open-source implementation for JRE, > but it still uncomplete, and, again, resistance to publish opensource code > for certification is looking ugly. > > So using a ''half-opened'' open-source solution, where specification is > controlled by not-very-opensource-friendly company for new open-source > product is really bad idea. > > > HTML5 is much more open standard, so using html5 is more proper solution. > > ... OK, let''s forget Linux. Looks at windows. IE will supports HTML5 out > of box. And future is looking promising. And how about Java? Yes, you need > to download it, install is separately, it starts to nagging about updates, > and it does not supports for windows system updates, so you need to update > it manually. Again, comparation Java VS HTML5 is not toward Java. > > >I have to agree with George here, the mere mention of java makes me want to burn this thing before it can breed. no matter how small you plan on making it, it could be done more efficiently in any other language. instead of allocating resources to my virtual machines we are now expected to allow how many hundreds of megabytes of memory to java ? No thanks, you can keep it. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I''ll set it up and give it a shot.. Heck I''d love to have a usable frontend for my junior admins to use. On Sat, Feb 11, 2012 at 11:53 PM, Jordan Tomkinson <jordan@moodle.com> wrote:> > > On Sun, Feb 12, 2012 at 8:03 AM, George Shuklin <george.shuklin@gmail.com> > wrote: >> >> >> >> ...but sorry, why do you use a richfat and plumby Java backend? There are >> a lot of smaller, ressource efficient, incomplex and easier to handle open >> source technologies - even full oo - available to build such a HTML >> management front- and even backend? >> >> We agree that in comparison to xm/xl/xe, running a Java stack might seem >> to be a bit on the heavy side. Yet we''d like to note that our back-end is >> nothing like Tomcat or Glassfish, it contains only the bare minimum needed >> to do its work. >> >> To elaborate choosing Java for our back-end: >> - Java applications can be deployed on a wide variety of operating >> systems, if not all. >> - Eventually the back-end will also be orchestrating pools or clusters. >> - The back-end parses responses and shrinks updates down to only the bare >> minimum, limiting bandwidth use by the front-end. >> - The back-end allows access to your servers over a single TCP/IP port, >> the Xen-API will not be publicly exposed. >> - Again we’re not running a whole Java EE stack, the front-end is a webapp >> that lives on its own and communicates with the backend over a WebSocket >> connection. >> - Coupled with Cassandra, the back-end is the only thing that needs to be >> run (one single instance), for any number of hosts. >> >> >> I''m very against Java. After Oracle license change sun-jre package was >> forced to be removed from the most distros. Right now Oracle does not >> properly supports any dpkg (deb) based Linux distrubition, providing only >> RPMs and some creepy tarball. This actually means ''very bad linux support''. >> And if we looks how Oracle do business we can see no future for nice >> multiplatform support. Yes, there is open-source implementation for JRE, but >> it still uncomplete, and, again, resistance to publish opensource code for >> certification is looking ugly. >> >> So using a ''half-opened'' open-source solution, where specification is >> controlled by not-very-opensource-friendly company for new open-source >> product is really bad idea. >> >> >> HTML5 is much more open standard, so using html5 is more proper solution. >> >> ... OK, let''s forget Linux. Looks at windows. IE will supports HTML5 out >> of box. And future is looking promising. And how about Java? Yes, you need >> to download it, install is separately, it starts to nagging about updates, >> and it does not supports for windows system updates, so you need to update >> it manually. Again, comparation Java VS HTML5 is not toward Java. >> >> > > I have to agree with George here, the mere mention of java makes me want to > burn this thing before it can breed. > no matter how small you plan on making it, it could be done more efficiently > in any other language. > instead of allocating resources to my virtual machines we are now expected > to allow how many hundreds of megabytes of memory to java ? > > No thanks, you can keep it. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users
On Sat, Feb 11, 2012 at 7:45 PM, Wannes De Smet <wannes321@gmail.com> wrote:> > The specification is controlled by the Executive Committee > (http://jcp.org/en/participation/committee). Sure, Oracle might be a major > influence, but saying they integrally control the specification is wrong. > And, by all means, cut Oracle some slack, their attitude towards open-source > was and still is improving.You should take a look at http://www.youtube.com/watch?v=-zRN7XLCRhc Especially starting around the 33:00 part. This is more about open solaris/zfs/dtrace and other technologies that Sun opensourced and then Oracle did not, but I think the same applies. FWIW, I''d have went with python myself. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer''s men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Wannes De Smet <wannes321@gmail.com> schrieb:>To elaborate choosing Java for our back-end: >- Java applications can be deployed on a wide variety of operating >systems, if not all.This was and still is the theory or marketing hint behind the concept of java which - as a goal - was not nearly reached until today as even java is not java on different implementations. I addition there still are versioning and licensing barriers for many users on different distros.>- Eventually the back-end will also be orchestrating pools or clusters.Ok, but this did not leads to java...>- The back-end parses responses and shrinks updates down to only the >bare minimum, limiting bandwidth use by the front-end.As typical daemons in such scenarios usually do...>- The back-end allows access to your servers over a single TCP/IP port, >the Xen-API will not be publicly exposed.Ok, sounds nice too, but has nothing to do with java.>- Again we’re not running a whole Java EE stack, the front-end is aThis would be completely overkill... ß)>webapp that lives on its own and communicates with the backend over a >WebSocket connection.Ok, so a typical software stack on such a machine would be: C (shell) Python Java VM any (other) Webframework/language? (Webserver) Why do you did not use any of the languages/scripting software still required/coming with a xen environment or any of the many faster plus smaller plus (until today) typically easier to handle/administer solutions for back- and frontend too (i.e. Python, Perl or C)? Writing a deamon in such languages is not a big job (see i.e. man perl-ipc) and there are many small to large module collections / web frameworks available on any levels and rfc.>- Coupled with Cassandra, the back-end is the only thing that needs to >be run (one single instance), for any number of hosts.Sorry, but until today and propably / at least within the next future in wont rely on any Java stuff within our productive xen / cloud systems. This may change at anytime within the future if Java would be able to clean out alle the steps it was/is behind other solutions. just my two cents here... Best regards and sorry for the noise, Niels. - -- Niels Dettenbach Syndicat IT&Internet http://www.syndicat.com -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iIEEAREIAEEFAk83nYM6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDbhOAJ97XYi1uZOS AwDNWh2Js+KqgaiscgCfbYm6L9kvp/71iH9jFhjteY+B2Po=wZb8 -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 12 Feb 2012, at 12:07, Niels Dettenbach (Syndicat IT&Internet) wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > Wannes De Smet <wannes321@gmail.com> schrieb: > >> To elaborate choosing Java for our back-end: >> - Java applications can be deployed on a wide variety of operating >> systems, if not all. > > This was and still is the theory or marketing hint behind the concept of java which - as a goal - was not nearly reached until today as even java is not java on different implementations.I think I''m missing something here, at the moment you can get a proper -- as in properly working, not certified -- JDK 7 build on Mac OSX, Debian, Fedora and even Windows, which lead me to believe Java''s availability is rather good.> > I addition there still are versioning and licensing barriers for many users on different distros. > > >> - Eventually the back-end will also be orchestrating pools or clusters. > Ok, > but this did not leads to java... > >> - The back-end parses responses and shrinks updates down to only the >> bare minimum, limiting bandwidth use by the front-end. > > As typical daemons in such scenarios usually do... > >> - The back-end allows access to your servers over a single TCP/IP port, >> the Xen-API will not be publicly exposed. > Ok, > sounds nice too, but has nothing to do with java. > >> - Again we’re not running a whole Java EE stack, the front-end is a > This would be completely overkill... ß) > >> webapp that lives on its own and communicates with the backend over a >> WebSocket connection. > > Ok, so a typical software stack on such a machine would be: > C > (shell) > Python > Java VM > any (other) Webframework/language? > (Webserver) > > Why do you did not use any of the languages/scripting software still required/coming with a xen environment or any of the many faster plus smaller plus (until today) typically easier to handle/administer solutions for back- and frontend too (i.e. Python, Perl or C)? Writing a deamon in such languages is not a big job (see i.e. man perl-ipc) and there are many small to large module collections / web frameworks available on any levels and rfc.Full disclosure: I chose Java because I know Java, I know what it is capable of and it is something I''ll happily defend. C is a tough nut to crack, if I were to rewrite the whole thing in C, the chance of me getting killed by an ice bear would be bigger than the backend working properly in about 5 months. Regarding Python and Perl: I don''t know them well enough to make a good argument, but until proven otherwise, I will maintain that Java is the most stable and easiest platform for our backend. (I am stating my opinion here, if you''d like to take this discussion further we should get ourselves a room :).> >> - Coupled with Cassandra, the back-end is the only thing that needs to >> be run (one single instance), for any number of hosts. > > > Sorry, but until today and propably / at least within the next future in wont rely on any Java stuff within our productive xen / cloud systems. This may change at anytime within the future if Java would be able to clean out alle the steps it was/is behind other solutions.I''m hoping Oracle plays nicely for the years to come, it seems like using Java in a FOSS environment today is like cursing on American television. To conclude: Java works (for us). One can only hope its reputation gets better in the years to come.> > just my two cents here... > > Best regards and sorry for the noise,Thanks for your opinion! Have a nice Sunday, W> > > Niels. > - -- > Niels Dettenbach > Syndicat IT&Internet > http://www.syndicat.com > -----BEGIN PGP SIGNATURE----- > Version: APG v1.0.8 > > iIEEAREIAEEFAk83nYM6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu > dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDbhOAJ97XYi1uZOS > AwDNWh2Js+KqgaiscgCfbYm6L9kvp/71iH9jFhjteY+B2Po> =wZb8 > -----END PGP SIGNATURE----- >
msgbox450-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2012-Feb-12 12:36 UTC
Re: Announcing XenMaster
This looks nice although I am not really sure I understand the angle you''re coming from here... You''re announcing a GUI, but the site is just a wiki with text and a bit of bashing vmware and windows but no screenshots of nice GUI designs or explanations of how yours will be better... In my view, XAPI already has a decent Windows GUI in the form of XenCenter, the bit we''re missing is a really good cross-platform and fully open gui base. Java isn''t a great choice for that due to the anti-java feelings around the community and GPL is also not a great choice given its viral nature. You seem to have a misunderstanding of the GPL in your wiki too when you say "the GPLv3 requires that everyone who improves our project, makes his work available publicly". It doesn''t - not if people just use it in house. People can make their own improvements all they like without releasing it. What the GPL actually means for anyone who wants to make a rebranded release of it for their clients or customers though, is that they will have to maintain a full archive of all the source going back all the versions, including all their little service-specific tweaks and then make it readily available to whoever wants it on request. In my view that just adds a lot of extra work and security considerations to any project that wants to use it. It also means no-one can add anything clever with it that gives them a competitive edge without releasing the source, so in that case they''ll probably choose to build a GUI from scratch rather than contribute anything. If we want a free, uncustomised proprietary windows GUI like VSphere Client then XenCenter does a great job. If we want a fully open, cross platform GUI that we can rebrand and customised for our own service offerings then we should be looking at something AJAX based with a BSD/MIT style license. Just my 10 cents ;) On 11 February 2012 19:14, Wannes De Smet <wannes321-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> *We''re happy to announce XenMaster, which has the ambitious goal to > become the de facto frontend for Xen with XCP. > > We''ve had the opportunity to present our project to some of the Xen/XCP > developers and now it''s time to announce the project to a larger public. > XenMaster, in short, is a HTML5 frontend coupled to a Java backend > delivering a rich UI for Xen, targeted at end users. > At the moment, one is able to successfully add NFS ISO repositories and > iSCSI/NFS storage repositories (iSCSI currently only works on XenServer > 5.6), create a HVM VM and control it via a VNC shell. > > Development thus far has been carried out by Jorgen Evens, frontend lead > and Wannes De Smet, project lead and backend developer. Of course, we now > would like to welcome you in becoming a tester and/or contributor! > You can find more information at xen-master.org, to install and configure > XenMaster <http://wiki.xen-master.org/wiki/Installing>. If you''d like to > help and have experience in developing Java and/or Javascript, load the > source in your favorite IDE and have at it! > > If you have any questions at all, we''ll be happy to answer them here or > through GitHub. > > We hope to welcome you in using XenMaster! > Jorgen Evens > Wannes De Smet > XenMaster * > > _______________________________________________ > xen-api mailing list > xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org > http://lists.xensource.com/mailman/listinfo/xen-api > >
Hey everyone, On Sun, Feb 12, 2012 at 1:28 PM, Wannes De Smet <wannes321@gmail.com> wrote:> On 12 Feb 2012, at 12:07, Niels Dettenbach (Syndicat IT&Internet) wrote: >[..]> I''m hoping Oracle plays nicely for the years to come, it seems like using Java in a FOSS environment today is like cursing on American television. > > To conclude: Java works (for us). One can only hope its reputation gets better in the years to come.Actually, besides being somewhat sluggish and fat ..and pretty verbose in its language part, Java had a pretty good reputation. Oracle did take care to undermine that reputation and will almost probably continue to look for opportunities of milking money out of Sun technoligies. @XenMaster: I would have expected any current Xen management front-end/framework to make use of and help advaince the libvirt project. Regards, Linus
2012/2/12 Linus van Geuns <linus@vangeuns.name>:> @XenMaster: I would have expected any current Xen management > front-end/framework to make use of and help advaince the libvirt > project.IMHO it''s a little much to expect *every* current software will make use of libvirt? I figure 90% of Xen (and other hypervisor) management tools use libvirt, and that is a quite reasonable amount. It totally makes sense for tools that aim to manage multiple types of hypervisors or multiple types of storage. For a XCP frontend it makes not much sense to base it libvirt since the direct XAPI access is more suited to manage SRs and other specialties and XCP does already abstract all of those. Managing multiple hypervisors is a great feature if you''re developing stuff (or for system integration like I do); but for real-world running virtual machines that are used by end-users? I don''t see the point. The admins will use ONE hypervisor on ONE type of OS (XCP) with ONE management tool. Florian -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Linus van Geuns <linus@vangeuns.name> schrieb:>in its language part, Java had a pretty good reputation.Yes, this is correct to, but afaik mainly in completely other applications scenarios, while there is nearly no halfway standard FOSS or *ixish system- or even system near management daemon written in Java and even tomcat had a much lower success then many peoples believed before (even if that solutions have some ideal application scenarios and are proven today) - with very good reasons i mean... btw: A state of the art cloud and vm orchestration solution should be alternatively usable by console in any way and/or usuable by scriptings aso. to be enterprise level. Realizing that in Java is possible, but administering or integrate that could be a mess for administrators. But this may just be my view... best regards, Niels. - -- Niels Dettenbach Syndicat IT&Internet http://www.syndicat.com -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iIEEAREIAEEFAk836OU6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDdcNAJ9MnYiXMCnP 8x7+TcZG95jKVgE9mQCcCXD+06fKs4fScerEhxuRBm+oLSk=xEDT -----END PGP SIGNATURE-----
Hi folks, There''s always OpenJDK as an alternative to Java. It would be a safe bet if Oracle decides to wring some money from Java. IMHO, there''s room for more GUI tools. For example, Citrix XenCenter does not work with Xen 4.1.2, though it works with XCP 1.1. I have considered most of the open source tools available for Xen administration, but I found them either a total overkill, or wanting for several reasons. Finally, I settled using the xl tool, which I find suits my needs (a bit crude, but does the job to the point). Regards, Peter On 12.2.2012 13:44, Linus van Geuns wrote:> Hey everyone, > > On Sun, Feb 12, 2012 at 1:28 PM, Wannes De Smet<wannes321@gmail.com> wrote: >> On 12 Feb 2012, at 12:07, Niels Dettenbach (Syndicat IT&Internet) wrote: >> > [..] >> I''m hoping Oracle plays nicely for the years to come, it seems like using Java in a FOSS environment today is like cursing on American television. >> >> To conclude: Java works (for us). One can only hope its reputation gets better in the years to come. > Actually, besides being somewhat sluggish and fat ..and pretty verbose > in its language part, Java had a pretty good reputation. > Oracle did take care to undermine that reputation and will almost > probably continue to look for opportunities of milking money out of > Sun technoligies. > > @XenMaster: I would have expected any current Xen management > front-end/framework to make use of and help advaince the libvirt > project. > > Regards, Linus > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2112/4805 - Release Date: 02/12/12
>Full disclosure: I chose Java because I know Java, I know what it iscapable of and it is something I''ll happily defend. C is a tough nut to crack, if I were to rewrite >the whole thing in C, the chance of me getting killed by an ice bear would be bigger than the backend working properly in about 5 months. Regarding Python and >Perl: I don''t know them well enough to make a good argument, but until proven otherwise, I will maintain that Java is the most stable and easiest platform for our >backend. (I am stating my opinion here, if you''d like to take this discussion further we should get ourselves a room :). This is usually the case. Every time I''ve had to do anything with Java it''s because the engineer leading the project learned it in school and it''s what they knew. I was willing to bet that this was the case where but I''m glad you said it. I''ve only allowed a java service on any of my servers once and it''s because there was no other options. Having said that I hope you well. Grant McWilliams http://grantmcwilliams.com/ Some people, when confronted with a problem, think "I know, I''ll use Windows." Now they have two problems. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Instead of harshing on your for using Java, I am going to say - Nicely done! I use either Linux or Mac OS X workstations, and have to run a VM of Windows if I want to use a GUI to manage my Xen boxes. I actually prefer to do the management via a GUI because I don''t have a lot of time to waste on trying to remember all of the commands to do stuff. Thank you for the hard work, I will certainly be giving it a try. Regards, Scott On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> We''re happy to announce XenMaster, which has the ambitious goal to become > the de facto frontend for Xen with XCP. > > We''ve had the opportunity to present our project to some of the Xen/XCP > developers and now it''s time to announce the project to a larger public. > XenMaster, in short, is a HTML5 frontend coupled to a Java backend > delivering a rich UI for Xen, targeted at end users. > At the moment, one is able to successfully add NFS ISO repositories and > iSCSI/NFS storage repositories (iSCSI currently only works on XenServer > 5.6), create a HVM VM and control it via a VNC shell. > > Development thus far has been carried out by Jorgen Evens, frontend lead and > Wannes De Smet, project lead and backend developer. Of course, we now would > like to welcome you in becoming a tester and/or contributor! > You can find more information at xen-master.org, to install and configure > XenMaster. If you''d like to help and have experience in developing Java > and/or Javascript, load the source in your favorite IDE and have at it! > > If you have any questions at all, we''ll be happy to answer them here or > through GitHub. > > We hope to welcome you in using XenMaster! > Jorgen Evens > Wannes De Smet > XenMaster > > _______________________________________________ > Xen-users mailing list > Xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org > http://lists.xensource.com/xen-users
I''d love to give it a try too but screenshots would have been better :) I''m not clear though on the list of features and I don''t find any on your site either. Good job! PS: try to get rid of java in the future On Mon, Feb 13, 2012 at 14:41, Scott Damron <sdamron@gmail.com> wrote:> Instead of harshing on your for using Java, I am going to say - Nicely > done! I use either Linux or Mac OS X workstations, and have to run a > VM of Windows if I want to use a GUI to manage my Xen boxes. I > actually prefer to do the management via a GUI because I don''t have a > lot of time to waste on trying to remember all of the commands to do > stuff. Thank you for the hard work, I will certainly be giving it a > try. > > Regards, > > Scott > > On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321@gmail.com> > wrote: > > We''re happy to announce XenMaster, which has the ambitious goal to become > > the de facto frontend for Xen with XCP. > > > > We''ve had the opportunity to present our project to some of the Xen/XCP > > developers and now it''s time to announce the project to a larger public. > > XenMaster, in short, is a HTML5 frontend coupled to a Java backend > > delivering a rich UI for Xen, targeted at end users. > > At the moment, one is able to successfully add NFS ISO repositories and > > iSCSI/NFS storage repositories (iSCSI currently only works on XenServer > > 5.6), create a HVM VM and control it via a VNC shell. > > > > Development thus far has been carried out by Jorgen Evens, frontend lead > and > > Wannes De Smet, project lead and backend developer. Of course, we now > would > > like to welcome you in becoming a tester and/or contributor! > > You can find more information at xen-master.org, to install and > configure > > XenMaster. If you''d like to help and have experience in developing Java > > and/or Javascript, load the source in your favorite IDE and have at it! > > > > If you have any questions at all, we''ll be happy to answer them here or > > through GitHub. > > > > We hope to welcome you in using XenMaster! > > Jorgen Evens > > Wannes De Smet > > XenMaster > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Screen shots are included on the Wiki... On Mon, Feb 13, 2012 at 7:19 AM, Ciprian Pantea <cipixul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''d love to give it a try too but screenshots would have been better :) > I''m not clear though on the list of features and I don''t find any on your > site either. > > > Good job! > PS: try to get rid of java in the future > > > On Mon, Feb 13, 2012 at 14:41, Scott Damron <sdamron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> Instead of harshing on your for using Java, I am going to say - Nicely >> done! I use either Linux or Mac OS X workstations, and have to run a >> VM of Windows if I want to use a GUI to manage my Xen boxes. I >> actually prefer to do the management via a GUI because I don''t have a >> lot of time to waste on trying to remember all of the commands to do >> stuff. Thank you for the hard work, I will certainly be giving it a >> try. >> >> Regards, >> >> Scott >> >> On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> > We''re happy to announce XenMaster, which has the ambitious goal to >> > become >> > the de facto frontend for Xen with XCP. >> > >> > We''ve had the opportunity to present our project to some of the Xen/XCP >> > developers and now it''s time to announce the project to a larger public. >> > XenMaster, in short, is a HTML5 frontend coupled to a Java backend >> > delivering a rich UI for Xen, targeted at end users. >> > At the moment, one is able to successfully add NFS ISO repositories and >> > iSCSI/NFS storage repositories (iSCSI currently only works on XenServer >> > 5.6), create a HVM VM and control it via a VNC shell. >> > >> > Development thus far has been carried out by Jorgen Evens, frontend lead >> > and >> > Wannes De Smet, project lead and backend developer. Of course, we now >> > would >> > like to welcome you in becoming a tester and/or contributor! >> > You can find more information at xen-master.org, to install and >> > configure >> > XenMaster. If you''d like to help and have experience in developing Java >> > and/or Javascript, load the source in your favorite IDE and have at it! >> > >> > If you have any questions at all, we''ll be happy to answer them here or >> > through GitHub. >> > >> > We hope to welcome you in using XenMaster! >> > Jorgen Evens >> > Wannes De Smet >> > XenMaster >> > >> > _______________________________________________ >> > Xen-users mailing list >> > Xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org >> > http://lists.xensource.com/xen-users >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org >> http://lists.xensource.com/xen-users > >
Oh yeah, sorry, didn''t find that last week. Does it support installations from templates and user based access? On Mon, Feb 13, 2012 at 15:21, Scott Damron <sdamron@gmail.com> wrote:> Screen shots are included on the Wiki... > > On Mon, Feb 13, 2012 at 7:19 AM, Ciprian Pantea <cipixul@gmail.com> wrote: > > I''d love to give it a try too but screenshots would have been better :) > > I''m not clear though on the list of features and I don''t find any on your > > site either. > > > > > > Good job! > > PS: try to get rid of java in the future > > > > > > On Mon, Feb 13, 2012 at 14:41, Scott Damron <sdamron@gmail.com> wrote: > >> > >> Instead of harshing on your for using Java, I am going to say - Nicely > >> done! I use either Linux or Mac OS X workstations, and have to run a > >> VM of Windows if I want to use a GUI to manage my Xen boxes. I > >> actually prefer to do the management via a GUI because I don''t have a > >> lot of time to waste on trying to remember all of the commands to do > >> stuff. Thank you for the hard work, I will certainly be giving it a > >> try. > >> > >> Regards, > >> > >> Scott > >> > >> On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321@gmail.com> > >> wrote: > >> > We''re happy to announce XenMaster, which has the ambitious goal to > >> > become > >> > the de facto frontend for Xen with XCP. > >> > > >> > We''ve had the opportunity to present our project to some of the > Xen/XCP > >> > developers and now it''s time to announce the project to a larger > public. > >> > XenMaster, in short, is a HTML5 frontend coupled to a Java backend > >> > delivering a rich UI for Xen, targeted at end users. > >> > At the moment, one is able to successfully add NFS ISO repositories > and > >> > iSCSI/NFS storage repositories (iSCSI currently only works on > XenServer > >> > 5.6), create a HVM VM and control it via a VNC shell. > >> > > >> > Development thus far has been carried out by Jorgen Evens, frontend > lead > >> > and > >> > Wannes De Smet, project lead and backend developer. Of course, we now > >> > would > >> > like to welcome you in becoming a tester and/or contributor! > >> > You can find more information at xen-master.org, to install and > >> > configure > >> > XenMaster. If you''d like to help and have experience in developing > Java > >> > and/or Javascript, load the source in your favorite IDE and have at > it! > >> > > >> > If you have any questions at all, we''ll be happy to answer them here > or > >> > through GitHub. > >> > > >> > We hope to welcome you in using XenMaster! > >> > Jorgen Evens > >> > Wannes De Smet > >> > XenMaster > >> > > >> > _______________________________________________ > >> > Xen-users mailing list > >> > Xen-users@lists.xensource.com > >> > http://lists.xensource.com/xen-users > >> > >> _______________________________________________ > >> Xen-users mailing list > >> Xen-users@lists.xensource.com > >> http://lists.xensource.com/xen-users > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 12, 2012 at 11:26 AM, Florian Heigl <florian.heigl@gmail.com> wrote:> 2012/2/12 Linus van Geuns <linus@vangeuns.name>: > >> @XenMaster: I would have expected any current Xen management >> front-end/framework to make use of and help advaince the libvirt >> project.<snip>> It totally makes sense > for tools that aim to manage multiple types of hypervisors or multiple > types of storage. > For a XCP frontend it makes not much sense to base it libvirt since > the direct XAPI access is more suited to manage SRs and other > specialties and XCP does already abstract all of those.Agreed. There are a lot of features that a generic tool like libvirt simply doesn''t support (as it is a common abstraction layer) and not purpose-built for Xen like XAPI and libxl are. Here is a summary of the choice of toolstacks: http://wiki.xen.org/wiki/Choice_of_Toolstacks Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://blog.xen.org/ http://wiki.xen.org/
> > > It totally makes sense > > for tools that aim to manage multiple types of hypervisors or multiple > > types of storage. > > For a XCP frontend it makes not much sense to base it libvirt since > > the direct XAPI access is more suited to manage SRs and other > > specialties and XCP does already abstract all of those. > > Agreed. There are a lot of features that a generic tool like libvirt > simply doesn''t support (as it is a common abstraction layer) and not > purpose-built for Xen like XAPI and libxl are. > > Here is a summary of the choice of toolstacks: > > http://wiki.xen.org/wiki/Choice_of_Toolstacks > > Thanks, > Todd > > -It looks like Todd that in the future XAPI and libvirt will both be using libxl underneath? I would also assume that this won''t change how XAPI works for a user/administrator but rather how it communicates with the Hypervisor? Grant McWilliams http://grantmcwilliams.com/ Some people, when confronted with a problem, think "I know, I''ll use Windows." Now they have two problems. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 13 Feb 2012, at 15:02, Todd Deshane wrote:> On Sun, Feb 12, 2012 at 11:26 AM, Florian Heigl <florian.heigl@gmail.com> wrote: >> 2012/2/12 Linus van Geuns <linus@vangeuns.name>: >> >>> @XenMaster: I would have expected any current Xen management >>> front-end/framework to make use of and help advaince the libvirt >>> project. > <snip> >> It totally makes sense >> for tools that aim to manage multiple types of hypervisors or multiple >> types of storage. >> For a XCP frontend it makes not much sense to base it libvirt since >> the direct XAPI access is more suited to manage SRs and other >> specialties and XCP does already abstract all of those. > > Agreed. There are a lot of features that a generic tool like libvirt > simply doesn''t support (as it is a common abstraction layer) and not > purpose-built for Xen like XAPI and libxl are.Indeed. As we mention on our site, we chose Xen via XCP and that''s it -- it doesn''t make much sense then for us to use libvirt. It may seem most things we''re currently doing can be done perfectly using libvirt, but later on we want to get into the nitty gritty details of Xen/XCP and properly use and/or expose them to the end-user. Another advantage is that we can integrate our own XAPI plugins, e.g. we currently ship a XAPI plugin to list available kernels on a Xen host. In the long run we want to deliver a stack (Xen/XCP/XenMaster) that is tightly connected and, well, just works. W> > Here is a summary of the choice of toolstacks: > > http://wiki.xen.org/wiki/Choice_of_Toolstacks > > Thanks, > Todd > > -- > Todd Deshane > http://www.linkedin.com/in/deshantm > http://blog.xen.org/ > http://wiki.xen.org/ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users
On 13 Feb 2012, at 14:59, Ciprian Pantea wrote:> Oh yeah, sorry, didn''t find that last week. Does it support installations from templates and user based access?They weren''t there yet last week :) -- people asked for them so we''ve put some screenshots on our site for your viewing pleasure. Templates will be supported in v1.0. User based access is somewhat more advanced, XCP has some kind of RBAC IIRC, properly understanding this and integrating it to support something like user access will probably take a while. Of course, you''re always welcome to contribute. W> > On Mon, Feb 13, 2012 at 15:21, Scott Damron <sdamron@gmail.com> wrote: > Screen shots are included on the Wiki... > > On Mon, Feb 13, 2012 at 7:19 AM, Ciprian Pantea <cipixul@gmail.com> wrote: > > I''d love to give it a try too but screenshots would have been better :) > > I''m not clear though on the list of features and I don''t find any on your > > site either. > > > > > > Good job! > > PS: try to get rid of java in the future > > > > > > On Mon, Feb 13, 2012 at 14:41, Scott Damron <sdamron@gmail.com> wrote: > >> > >> Instead of harshing on your for using Java, I am going to say - Nicely > >> done! I use either Linux or Mac OS X workstations, and have to run a > >> VM of Windows if I want to use a GUI to manage my Xen boxes. I > >> actually prefer to do the management via a GUI because I don''t have a > >> lot of time to waste on trying to remember all of the commands to do > >> stuff. Thank you for the hard work, I will certainly be giving it a > >> try. > >> > >> Regards, > >> > >> Scott > >> > >> On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321@gmail.com> > >> wrote: > >> > We''re happy to announce XenMaster, which has the ambitious goal to > >> > become > >> > the de facto frontend for Xen with XCP. > >> > > >> > We''ve had the opportunity to present our project to some of the Xen/XCP > >> > developers and now it''s time to announce the project to a larger public. > >> > XenMaster, in short, is a HTML5 frontend coupled to a Java backend > >> > delivering a rich UI for Xen, targeted at end users. > >> > At the moment, one is able to successfully add NFS ISO repositories and > >> > iSCSI/NFS storage repositories (iSCSI currently only works on XenServer > >> > 5.6), create a HVM VM and control it via a VNC shell. > >> > > >> > Development thus far has been carried out by Jorgen Evens, frontend lead > >> > and > >> > Wannes De Smet, project lead and backend developer. Of course, we now > >> > would > >> > like to welcome you in becoming a tester and/or contributor! > >> > You can find more information at xen-master.org, to install and > >> > configure > >> > XenMaster. If you''d like to help and have experience in developing Java > >> > and/or Javascript, load the source in your favorite IDE and have at it! > >> > > >> > If you have any questions at all, we''ll be happy to answer them here or > >> > through GitHub. > >> > > >> > We hope to welcome you in using XenMaster! > >> > Jorgen Evens > >> > Wannes De Smet > >> > XenMaster > >> > > >> > _______________________________________________ > >> > Xen-users mailing list > >> > Xen-users@lists.xensource.com > >> > http://lists.xensource.com/xen-users > >> > >> _______________________________________________ > >> Xen-users mailing list > >> Xen-users@lists.xensource.com > >> http://lists.xensource.com/xen-users > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Np glad it''s possible and that you have it in the roadmap. Congrats on your work. On Mon, Feb 13, 2012 at 18:12, Wannes De Smet <wannes321@gmail.com> wrote:> On 13 Feb 2012, at 14:59, Ciprian Pantea wrote: > > Oh yeah, sorry, didn''t find that last week. Does it support installations > from templates and user based access? > > > They weren''t there yet last week :) -- people asked for them so we''ve put > some screenshots on our site for your viewing pleasure. > > Templates will be supported in v1.0. User based access is somewhat more > advanced, XCP has some kind of RBAC IIRC, properly understanding this and > integrating it to support something like user access will probably take a > while. > Of course, you''re always welcome to contribute. > > W > > > On Mon, Feb 13, 2012 at 15:21, Scott Damron <sdamron@gmail.com> wrote: > >> Screen shots are included on the Wiki... >> >> On Mon, Feb 13, 2012 at 7:19 AM, Ciprian Pantea <cipixul@gmail.com> >> wrote: >> > I''d love to give it a try too but screenshots would have been better :) >> > I''m not clear though on the list of features and I don''t find any on >> your >> > site either. >> > >> > >> > Good job! >> > PS: try to get rid of java in the future >> > >> > >> > On Mon, Feb 13, 2012 at 14:41, Scott Damron <sdamron@gmail.com> wrote: >> >> >> >> Instead of harshing on your for using Java, I am going to say - Nicely >> >> done! I use either Linux or Mac OS X workstations, and have to run a >> >> VM of Windows if I want to use a GUI to manage my Xen boxes. I >> >> actually prefer to do the management via a GUI because I don''t have a >> >> lot of time to waste on trying to remember all of the commands to do >> >> stuff. Thank you for the hard work, I will certainly be giving it a >> >> try. >> >> >> >> Regards, >> >> >> >> Scott >> >> >> >> On Sat, Feb 11, 2012 at 1:00 PM, Wannes De Smet <wannes321@gmail.com> >> >> wrote: >> >> > We''re happy to announce XenMaster, which has the ambitious goal to >> >> > become >> >> > the de facto frontend for Xen with XCP. >> >> > >> >> > We''ve had the opportunity to present our project to some of the >> Xen/XCP >> >> > developers and now it''s time to announce the project to a larger >> public. >> >> > XenMaster, in short, is a HTML5 frontend coupled to a Java backend >> >> > delivering a rich UI for Xen, targeted at end users. >> >> > At the moment, one is able to successfully add NFS ISO repositories >> and >> >> > iSCSI/NFS storage repositories (iSCSI currently only works on >> XenServer >> >> > 5.6), create a HVM VM and control it via a VNC shell. >> >> > >> >> > Development thus far has been carried out by Jorgen Evens, frontend >> lead >> >> > and >> >> > Wannes De Smet, project lead and backend developer. Of course, we now >> >> > would >> >> > like to welcome you in becoming a tester and/or contributor! >> >> > You can find more information at xen-master.org, to install and >> >> > configure >> >> > XenMaster. If you''d like to help and have experience in developing >> Java >> >> > and/or Javascript, load the source in your favorite IDE and have at >> it! >> >> > >> >> > If you have any questions at all, we''ll be happy to answer them here >> or >> >> > through GitHub. >> >> > >> >> > We hope to welcome you in using XenMaster! >> >> > Jorgen Evens >> >> > Wannes De Smet >> >> > XenMaster >> >> > >> >> > _______________________________________________ >> >> > Xen-users mailing list >> >> > Xen-users@lists.xensource.com >> >> > http://lists.xensource.com/xen-users >> >> >> >> _______________________________________________ >> >> Xen-users mailing list >> >> Xen-users@lists.xensource.com >> >> http://lists.xensource.com/xen-users >> > >> > >> > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I''m reluctant to further a thread that''s already off-topic, but two of these sub-topics cause me considerable heartburn...> -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > bounces@lists.xensource.com] On Behalf Of Linus van Geuns > Sent: Sunday, February 12, 2012 7:44 AM > > > To conclude: Java works (for us). One can only hope its reputation gets better in the > years to come. > > Actually, besides being somewhat sluggish and fat ..and pretty verbose in its language > part, Java had a pretty good reputation."reputation" is the operative word in your post. Ii may or may not be supported by facts. Words like sluggish/fat/verbose are merely opinions without supporting arguments (and I don''t want to argue them here). The choice of development language is the wrong debate anyway. There are plenty of examples of high-quality code written in Java, and you''ll generally find these are simple to install, easy to run, and perform well. I''ve also been forced to use Java code that produces frequent OOM errors, NPE exceptions, deadlocks, etc. But I doubt it''s difficult to find good and bad examples of just about any development language. It may be that the average experience level of Java programmers is shorter than for other languages, as someone else suggested. That may be important to understanding Java''s reputation, but it''s not important to the XenMaster project. I personally welcome the opportunity to work with another well engineered, carefully designed OSS project regardless of choice of development language. BTW, please don''t remind me what Oracle is or isn''t doing with Java. I''ve heard it before. Leave that discussion to the tabloids, not a technical user forum.> @XenMaster: I would have expected any current Xen management front- > end/framework to make use of and help advaince the libvirt project.Depends on the project''s goals. My understanding of libvirt is that it is meant to be an abstraction layer to support Xen, KVM and other hypervisors. That''s not important if the project''s sole focus is Xen/XCP. Libvirt won''t add anything in that case, and it may in fact get in the way. (My own, brief experiments with libvirt involved installing packages, following the documentation, troubleshooting libvirt and ultimately ignoring it. Then everything began to work. It was clear the Xen packages I was using at the time were more mature and/or fully tested than libvirt. YMMV.) -Jeff
On Mon, Feb 13, 2012 at 10:14 AM, Grant McWilliams <grantmasterflash@gmail.com> wrote:>> > It totally makes sense >> > for tools that aim to manage multiple types of hypervisors or multiple >> > types of storage. >> > For a XCP frontend it makes not much sense to base it libvirt since >> > the direct XAPI access is more suited to manage SRs and other >> > specialties and XCP does already abstract all of those. >> >> Agreed. There are a lot of features that a generic tool like libvirt >> simply doesn''t support (as it is a common abstraction layer) and not >> purpose-built for Xen like XAPI and libxl are. >> >> Here is a summary of the choice of toolstacks: >> >> http://wiki.xen.org/wiki/Choice_of_Toolstacks > > It looks like Todd that in the future XAPI and libvirt will both be using > libxl underneath?libvirt already has a libxl port. XAPI''s libxl port is still in progress.> I would also assume that this won''t change how XAPI works > for a user/administrator but rather how it communicates with the Hypervisor?Right, the point of libxl is doing the "bottom third" of any Xen-based toolstack and doing it well. XAPI, libvirt, or any other toolstack can then innovate on top of that. Porting XAPI to a libxl base will likely just make it faster, more maintainable, and compatible with libxl-based development. The admin or developer API will not be affected by the libxl port. Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://blog.xen.org/ http://wiki.xen.org/
Thank you, Jeff. You are one of a very few voices of reason in this debate. Folks, if you don''t like Java-based software, or have some view of why no one should be using Java because of what "big bad Oracle" is doing with the licensing of it, don''t use the software. It''s that simple. All these folks are doing is letting those of us who are interested know of a project for managing Xen-based systems. I also welcome such a project, regardless of the programming language in which it is written, especially since there seems to be a distinct lack of good, stable, complete, and easy-to-use management software out there for XCP (and XenServer). Some of us would welcome a Java-based project that would keep us from having to run a Windows system simply to manage our XCP and XenServer instances. You need not attack the writers of the XenMaster code for their choices - it only serves to discourage them from being part of this community and from continuing their efforts to make software available to this community. -Nick On Mon, 2012-02-13 at 21:40 +0000, Jeff Sturm wrote:> I''m reluctant to further a thread that''s already off-topic, but two of these sub-topics cause me considerable heartburn... > > > -----Original Message----- > > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > > bounces@lists.xensource.com] On Behalf Of Linus van Geuns > > Sent: Sunday, February 12, 2012 7:44 AM > > > > > To conclude: Java works (for us). One can only hope its reputation gets better in the > > years to come. > > > > Actually, besides being somewhat sluggish and fat ..and pretty verbose in its language > > part, Java had a pretty good reputation. > > "reputation" is the operative word in your post. Ii may or may not be supported by facts. Words like sluggish/fat/verbose are merely opinions without supporting arguments (and I don''t want to argue them here). > > The choice of development language is the wrong debate anyway. There are plenty of examples of high-quality code written in Java, and you''ll generally find these are simple to install, easy to run, and perform well. I''ve also been forced to use Java code that produces frequent OOM errors, NPE exceptions, deadlocks, etc. But I doubt it''s difficult to find good and bad examples of just about any development language. > > It may be that the average experience level of Java programmers is shorter than for other languages, as someone else suggested. That may be important to understanding Java''s reputation, but it''s not important to the XenMaster project. I personally welcome the opportunity to work with another well engineered, carefully designed OSS project regardless of choice of development language. > > BTW, please don''t remind me what Oracle is or isn''t doing with Java. I''ve heard it before. Leave that discussion to the tabloids, not a technical user forum. > > > @XenMaster: I would have expected any current Xen management front- > > end/framework to make use of and help advaince the libvirt project. > > Depends on the project''s goals. My understanding of libvirt is that it is meant to be an abstraction layer to support Xen, KVM and other hypervisors. That''s not important if the project''s sole focus is Xen/XCP. Libvirt won''t add anything in that case, and it may in fact get in the way. (My own, brief experiments with libvirt involved installing packages, following the documentation, troubleshooting libvirt and ultimately ignoring it. Then everything began to work. It was clear the Xen packages I was using at the time were more mature and/or fully tested than libvirt. YMMV.) > > -Jeff > > > >-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
But still being part of this community enables one and gives him the right to say his mind especially if he considers that he might contribute. Now maybe some of the people here may not have been as diplomat as possible, but they gave some feedback and they represent part of the community that wants to use this software, has a problem with java and took the time to say what they have on their minds... I too shall use the software even if it''s based on java but I don''t have to like it and if I can talk with the developers, why not speak my mind and say what I think about java? Hope my reasoning is clear. Cheers! Ciprian On Tue, Feb 14, 2012 at 18:57, Nick Couchman <Nick.Couchman@seakr.com>wrote:> Thank you, Jeff. You are one of a very few voices of reason in this > debate. > > Folks, if you don''t like Java-based software, or have some view of why > no one should be using Java because of what "big bad Oracle" is doing > with the licensing of it, don''t use the software. It''s that simple. > All these folks are doing is letting those of us who are interested know > of a project for managing Xen-based systems. I also welcome such a > project, regardless of the programming language in which it is written, > especially since there seems to be a distinct lack of good, stable, > complete, and easy-to-use management software out there for XCP (and > XenServer). Some of us would welcome a Java-based project that would > keep us from having to run a Windows system simply to manage our XCP and > XenServer instances. > > You need not attack the writers of the XenMaster code for their choices > - it only serves to discourage them from being part of this community > and from continuing their efforts to make software available to this > community. > > -Nick > > On Mon, 2012-02-13 at 21:40 +0000, Jeff Sturm wrote: > > I''m reluctant to further a thread that''s already off-topic, but two of > these sub-topics cause me considerable heartburn... > > > > > -----Original Message----- > > > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > > > bounces@lists.xensource.com] On Behalf Of Linus van Geuns > > > Sent: Sunday, February 12, 2012 7:44 AM > > > > > > > To conclude: Java works (for us). One can only hope its reputation > gets better in the > > > years to come. > > > > > > Actually, besides being somewhat sluggish and fat ..and pretty verbose > in its language > > > part, Java had a pretty good reputation. > > > > "reputation" is the operative word in your post. Ii may or may not be > supported by facts. Words like sluggish/fat/verbose are merely opinions > without supporting arguments (and I don''t want to argue them here). > > > > The choice of development language is the wrong debate anyway. There > are plenty of examples of high-quality code written in Java, and you''ll > generally find these are simple to install, easy to run, and perform well. > I''ve also been forced to use Java code that produces frequent OOM errors, > NPE exceptions, deadlocks, etc. But I doubt it''s difficult to find good > and bad examples of just about any development language. > > > > It may be that the average experience level of Java programmers is > shorter than for other languages, as someone else suggested. That may be > important to understanding Java''s reputation, but it''s not important to the > XenMaster project. I personally welcome the opportunity to work with > another well engineered, carefully designed OSS project regardless of > choice of development language. > > > > BTW, please don''t remind me what Oracle is or isn''t doing with Java. > I''ve heard it before. Leave that discussion to the tabloids, not a > technical user forum. > > > > > @XenMaster: I would have expected any current Xen management front- > > > end/framework to make use of and help advaince the libvirt project. > > > > Depends on the project''s goals. My understanding of libvirt is that it > is meant to be an abstraction layer to support Xen, KVM and other > hypervisors. That''s not important if the project''s sole focus is Xen/XCP. > Libvirt won''t add anything in that case, and it may in fact get in the > way. (My own, brief experiments with libvirt involved installing packages, > following the documentation, troubleshooting libvirt and ultimately > ignoring it. Then everything began to work. It was clear the Xen packages > I was using at the time were more mature and/or fully tested than libvirt. > YMMV.) > > > > -Jeff > > > > > > > > > > > > -------- > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient. If this email is not intended for you, or > you are not responsible for the delivery of this message to the intended > recipient, please note that this message may contain SEAKR Engineering > (SEAKR) Privileged/Proprietary Information. In such a case, you are > strictly prohibited from downloading, photocopying, distributing or > otherwise using this message, its contents or attachments in any way. If > you have received this message in error, please notify us immediately by > replying to this e-mail and delete the message from your mailbox. > Information contained in this message that does not relate to the business > of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nick Couchman <Nick.Couchman@seakr.com> schrieb:>Thank you, Jeff. You are one of a very few voices of reason in this >debate. > >Folks, if you don't like Java-based software, or have some view of why >no one should be using Java because of what "big bad Oracle" is doing >with the licensing of it, don't use the software.At least this is not my position or you did not got the point about my one. There still are good reasons why system many administrators want to avoid java based software as far as possible. I like Java software in a lot of scenarios - i.e. on smartphones or even in ERP solutions - but not in a system management daemon. What Oracle does is not my thing because i'm not related to them and Java by specification too afaik today. Compared to other typical solutions java vms easily are hundreds of MB large and waste a lot of main memory too, are difficult to debug and slower then most other stuff. Until today Java still is not Java (means that most Java apps did behave different on different VMs or just did not run with more or less of them and this has to be tested in detail...) and the licensing differencies still leaded to a non integration of Java (except the free ones) in many current repositories what means that they have to handled partly or fully by hand instead by the typical software management automatics / package or build managements. But, a point for your side - the commercial windows based management suite is not an alternative to many of us too... ß)> It's that simple.unfortunately, yes... Anyhow, i wish you all the best and a lot of success with your project. cheers, Niels. - -- Niels Dettenbach Syndicat IT&Internet http://www.syndicat.com -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iIEEAREIAEEFAk86m306HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDdtyAJ9zJXSTY8Bf jrPT3j3+0X8q2FTfyQCfRGlUlhXAPARPwSld1H408WNQNwg=qEkK -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi all, As you might have expected the "I HATE JAVA/ORACLE/..." (I''m exaggerating) part wasn''t that helpful for us. On the other hand we now know what people mean when they react this way, and we can at least try to anticipate this for future events. We thank everyone who voiced his concerns or defended our choices. However, we''d like to kindly ask you to let this argument slide, it''s gone a bit off-topic and we would love to actually get some feedback on our functionality rather than on the platform we use. If you do want to take this argument further, you can find our contact details at http://wiki.xen-master.org/wiki/Contact. And don''t forget: the Xen hackathlon ( http://wiki.xen.org/wiki/Hackathon/March2012 ) this year is hosted by … Oracle ;) Thank you, W PS We''re planning to have our own mailing list up and running this weekend to offload this thread from the xen-users/xen-api lists. On 14 Feb 2012, at 18:20, Ciprian Pantea wrote:> But still being part of this community enables one and gives him the right to say his mind > especially if he considers that he might contribute. > > Now maybe some of the people here may not have been as diplomat as possible, but > they gave some feedback and they represent part of the community that wants to > use this software, has a problem with java and took the time to say what they have > on their minds... > > I too shall use the software even if it''s based on java but I don''t have to like it and if I can > talk with the developers, why not speak my mind and say what I think about java? > > Hope my reasoning is clear. Cheers! > > Ciprian > > On Tue, Feb 14, 2012 at 18:57, Nick Couchman <Nick.Couchman@seakr.com> wrote: > Thank you, Jeff. You are one of a very few voices of reason in this > debate. > > Folks, if you don''t like Java-based software, or have some view of why > no one should be using Java because of what "big bad Oracle" is doing > with the licensing of it, don''t use the software. It''s that simple. > All these folks are doing is letting those of us who are interested know > of a project for managing Xen-based systems. I also welcome such a > project, regardless of the programming language in which it is written, > especially since there seems to be a distinct lack of good, stable, > complete, and easy-to-use management software out there for XCP (and > XenServer). Some of us would welcome a Java-based project that would > keep us from having to run a Windows system simply to manage our XCP and > XenServer instances. > > You need not attack the writers of the XenMaster code for their choices > - it only serves to discourage them from being part of this community > and from continuing their efforts to make software available to this > community. > > -Nick > > On Mon, 2012-02-13 at 21:40 +0000, Jeff Sturm wrote: > > I''m reluctant to further a thread that''s already off-topic, but two of these sub-topics cause me considerable heartburn... > > > > > -----Original Message----- > > > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > > > bounces@lists.xensource.com] On Behalf Of Linus van Geuns > > > Sent: Sunday, February 12, 2012 7:44 AM > > > > > > > To conclude: Java works (for us). One can only hope its reputation gets better in the > > > years to come. > > > > > > Actually, besides being somewhat sluggish and fat ..and pretty verbose in its language > > > part, Java had a pretty good reputation. > > > > "reputation" is the operative word in your post. Ii may or may not be supported by facts. Words like sluggish/fat/verbose are merely opinions without supporting arguments (and I don''t want to argue them here). > > > > The choice of development language is the wrong debate anyway. There are plenty of examples of high-quality code written in Java, and you''ll generally find these are simple to install, easy to run, and perform well. I''ve also been forced to use Java code that produces frequent OOM errors, NPE exceptions, deadlocks, etc. But I doubt it''s difficult to find good and bad examples of just about any development language. > > > > It may be that the average experience level of Java programmers is shorter than for other languages, as someone else suggested. That may be important to understanding Java''s reputation, but it''s not important to the XenMaster project. I personally welcome the opportunity to work with another well engineered, carefully designed OSS project regardless of choice of development language. > > > > BTW, please don''t remind me what Oracle is or isn''t doing with Java. I''ve heard it before. Leave that discussion to the tabloids, not a technical user forum. > > > > > @XenMaster: I would have expected any current Xen management front- > > > end/framework to make use of and help advaince the libvirt project. > > > > Depends on the project''s goals. My understanding of libvirt is that it is meant to be an abstraction layer to support Xen, KVM and other hypervisors. That''s not important if the project''s sole focus is Xen/XCP. Libvirt won''t add anything in that case, and it may in fact get in the way. (My own, brief experiments with libvirt involved installing packages, following the documentation, troubleshooting libvirt and ultimately ignoring it. Then everything began to work. It was clear the Xen packages I was using at the time were more mature and/or fully tested than libvirt. YMMV.) > > > > -Jeff > > > > > > > > > > > > -------- > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 14 Feb 2012 09:57:01 -0700 "Nick Couchman" <Nick.Couchman@seakr.com> wrote:> You need not attack the writers of the XenMaster code for their > choices > - it only serves to discourage them from being part of this community > and from continuing their efforts to make software available to this > community.+1 to this, and to the OP. Thanks Wannes for your announcement. Be assured that there are also people who do not immediately reply but still really appreciate the contribution. I''m one of them. Mark