Re: VCL, is this name kosher?
On Mar 3, 2009, at 12:42 PM, sam averitt wrote: Question: Suppose the project name became CloudMaker. Would it not be permissible to call the NC State cloud, NCSU CloudMaker or NC State's CloudMaker? That would not be possible. Maybe one way to make it more clear is assume that NCSU is IBM and we are Amazon. Does this statement sound permissible: Would it be permissible to call the IBM cloud, IBM Electronic Computing Cloud or IBM's Electronic Computing Cloud? That would definitely not fly for either parties and, so, would not work here. So what you are saying is that it doesn't matter what the name, either formal or common, AFS rules require a different name? Correct, our project name has to be different. Among other more recent names we considered was VCloud -- Virtual Cloud as in cloud of clouds. Would VCloud be an acceptable ASF name? VCloud might be fine. Anything other than VCL. However, once it's understood that the name has to change, it's the ASF community that gets to decide on the new name. Regards, Alan Sam -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, March 03, 2009 12:17 AM To: vcl-dev@incubator.apache.org Subject: Re: VCL, is this name kosher? On Mar 2, 2009, at 6:31 PM, sam averitt wrote: A simple suggestion on the name - that VCL be "transferred" to Apache.org and become the official project name. Current users of VCL already wrap their own identity around VCL. NC State would/could still use the qualified name NCSU VCL or NC State's VCL and others would/could do likewise. For example the Virginia group already calls their initiative Virginia VCL. Unfortunately that's all the more reason for the ASF project to change its name. I believe there are no specific acknowledgement requirements for use of apache.org software? Meaning that anyone could add a personalized qualifier or not and a root linkage statement (like powered by Apache.org's VCL) or not. Project attribution should not be confused with with the department. To be sure NCSU could use Apache VCL, install it, use it, and provide attribution. However, having the progenitor keep its name, VCL, causes a conflict that needs to be resolved. This issue can easily be solved by having this project choose a new name. Seems to me that providing a combined personal identifier and default root linkage mechanism would help, not hurt the Apache brand. Attribution is always appreciated but it's a not very convincing argument for the ASF keeping a name that is at odds with its progenitor's and now other universities' project names, VCL. What I can say is that this assessment is consistent with and supported by our experience to date. NCSU VCL and its developers have a lot to be proud of. It's only natural that both, NCSU VCL and its developers at ASF VCL, would want to keep their association with the brand. That brand is only strengthened as departments from other universities join in and have their initiatives participate in the VCL brand. Unfortunately the ASF must remain independent this branding effort. Regards, Alan
Re: a hypervisor's username & password
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu March 5 2009 3:41:47 pm Aaron Peeler wrote: > option 2 - vmprofile table is the definitely the correct location to store > this type of data. > > Whichever table it goes in, here are the lines to be added to the vcl.sql > > file: > > > > `username` varchar(8) NOT NULL default '' > > `password` varchar(40) NOT NULL default '' These should be allowed to be NULL with a default value of NULL since they will exist for every vmprofile, including those that do not require these fields. Also, are you sure ESXi limits the username to 8 characters? Josh - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJsD+XV/LQcNdtPQMRAtJSAJsEV/QcbIPmukSzDP9uhxKuhUGNawCfX3ar PJ/6OqBsttA5YaoOKt6C+kQ= =Obs6 -END PGP SIGNATURE-
Re: a hypervisor's username & password
option 2 - vmprofile table is the definitely the correct location to store this type of data. The vmhost table will eventually only have 4 columns id,computerid,vmlimit,vmprofileid.All additional info about a given hypervisor should in a profile. After extending the database - we'll need to extend the query in utils::get_vmhost_info routine Are there any other variables for the esx module that should go into the vmprofile table? Aaron --On March 5, 2009 3:19:20 PM -0500 Brian Bouterse wrote: Heretofore, VCL SSH's to a hypervisor when it wants to cause some change (ie: provision or deprovision a VM). The VCL uses pre-shared SSH keys between VCL and the hypervisor to allow the SSHing the authenticate. This works for VMware server and regular ESX because they are configurable to accept SSH keys. ESX 3i isn't configurable to accept an SSH logon, and can only be communicated with through a web service which requires a valid hypervisor username and password. So I'd like to propose that we add a hypervisor username and password in the VCL database associated. As far as I can tell, there are two places to add this information. 1) Extend the 'vmhost' table to include a username field and a password field. This would allow each individual hypervisor to have its own user/pass. However, if all the hypervisors use the same user/pass then we've just duplicated a lot of data, and it is very hard to change this system wide password later. 2) Extend the 'vmprofile' table to include a username field and a password. In this case a group of hypervisors (linked through the same vmprofile) would share a single user/pass. This would make password changes easier since it only has to be updated in one place, but requires hypervisors to have a consistant username/password across them. Because of the de-duplication of data, and easyness of password changes, I favor of this second option. Whichever table it goes in, here are the lines to be added to the vcl.sql file: `username` varchar(8) NOT NULL default '' `password` varchar(40) NOT NULL default '' Could someone tell us a bit about how to get that username and password out of the database and into our module as a variable? Best, Brian Brian Bouterse Secure Open Systems Initiative 919.698.8796 Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu
a hypervisor's username & password
Heretofore, VCL SSH's to a hypervisor when it wants to cause some change (ie: provision or deprovision a VM). The VCL uses pre-shared SSH keys between VCL and the hypervisor to allow the SSHing the authenticate. This works for VMware server and regular ESX because they are configurable to accept SSH keys. ESX 3i isn't configurable to accept an SSH logon, and can only be communicated with through a web service which requires a valid hypervisor username and password. So I'd like to propose that we add a hypervisor username and password in the VCL database associated. As far as I can tell, there are two places to add this information. 1) Extend the 'vmhost' table to include a username field and a password field. This would allow each individual hypervisor to have its own user/pass. However, if all the hypervisors use the same user/ pass then we've just duplicated a lot of data, and it is very hard to change this system wide password later. 2) Extend the 'vmprofile' table to include a username field and a password. In this case a group of hypervisors (linked through the same vmprofile) would share a single user/pass. This would make password changes easier since it only has to be updated in one place, but requires hypervisors to have a consistant username/password across them. Because of the de-duplication of data, and easyness of password changes, I favor of this second option. Whichever table it goes in, here are the lines to be added to the vcl.sql file: `username` varchar(8) NOT NULL default '' `password` varchar(40) NOT NULL default '' Could someone tell us a bit about how to get that username and password out of the database and into our module as a variable? Best, Brian Brian Bouterse Secure Open Systems Initiative 919.698.8796
Re: Image capture improvements and API development
The commits I made on 2/26 extended the state modules with the new flow described in this thread. Up to this point, nothing has functionally changed because none of the provisioning or OS modules have been committed which have been modified to use the new flow. The image capture flow changes and OS modularization that I'm working on are very intertwined. Vista.pm was the first attempt at modularization and the next step is to get the other Windows OS's working in the same fashion. I want to take steps so the code that's already working isn't affected. Here's how I intend to do this... See the diagram at the top of this page: http://cwiki.apache.org/confluence/display/VCL/Operating%20System%20Module%20Inheritance The current Windows OS modules are using or inheriting from Windows.pm, Desktop.pm, and Vista.pm. I don't want to change these at all. I plan to commit new files named Windows_mod.pm, Version_5.pm, Version_6.pm, XP_mod.pm, and Vista_mod.pm, as shown on the right side of the diagram. This will allow us to work on and test the new modules without affecting existing, working code. Once tested and everyone's comfortable with the modularized code, the old files can be removed and Windows_mod.pm will be renamed Windows.pm, etc. Much of the code is not actually new. Several subroutines were copied from Vista.pm because they work for any Windows OS. It's possible to use the old code and test new in parallel because of the way the database was designed to handle modularization. All that needs to be done is to create a new entry in the OS table (call it XP_mod) and a corresponding entry in the module table with its module.perlpackage column pointing to XP_mod.pm. Any images you configure with the image.OSid pointing to the new XP_mod OS type will receive the new code. All of existing XP images will not be affected. I have begun to document this on the page noted above. The file named Version_5.pm and Version_6.pm will replace Desktop.pm and Server.pm (which doesn't actually exist). After working with the different Windows versions and seeing where the major differences lie, it makes more sense to organize the Windows inheritance tree by Windows major version rather than desktop/server. I have a good bit of the new layout done and will commit it soon if there are no objections. Please let me know if you have any questions, ideas, or want to help. Thanks, Andy Andy Kurth wrote: Thanks to everyone for the feedback. I'll begin working on the proposed changes today. Thanks, Andy Aaron Peeler wrote: I like these changes also, this falls in line with our overall modularization goal. Aaron --On February 12, 2009 3:48:30 PM -0500 Andy Kurth wrote: I would like to begin defining and documenting the API for the backend code as people are actively working on developing new modules. I have begun some pages on the Confluence site and would like to start discussing this. API development is somewhat related to the image capture and modularization issues discussed at the meeting on 2/5. Solving the issues requires the modularization architecture to be modified and the API should be specified/updated along the way. The main problem is that xCAT.pm expects the OS to reboot when the OS capture tasks are done and vmware.pm needs the OS to shut down. xCAT.pm is currently the only provisioning module which has had the OS-specific code removed and is fully modularized. vmware.pm still contains OS code. It will be difficult to modularize vmware.pm and the ESX.pm module that Brian and Andrew are working on because of this. I have given it some thought and would like to propose the numbered changes below. These changes probably sound bigger than they really are. Minor changes would need to be made to xCAT.pm and image.pm. This will be easier to understand if you look at the diagram on the following page: http://cwiki.apache.org/confluence/display/VCL/Image+Capture+Sequence 1. The name of the OS module's capture_prepare subroutine will be changed to pre_capture(). The reason for this is to align the name of the main OS capture subroutine with the main OS load subroutine - pre_capture() and post_load(). 2. image.pm will no longer call the OS::pre_capture() subroutine. It will be the provisioning module's responsibility to do this. This allows the provisioning module to have greater control over the capture sequence. image.pm will only call the provisioning module's capture() subroutine. This makes better sense to me because provisioning engines can be quite varied and the sequence should really be driven by the provisioning module. 3. OS::pre_capture() will accept an optional argument named 'end_state' with possible values 'on', 'off', 'reboot'. This instructs OS::pre_capture() what to do after completing its image capture steps. Because pre_capture() will be called by the provisioning module, the provisioning module will be able to have th
Re: another user for system tasks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I created VCL-102 for this. Josh On Thu March 5 2009 11:17:47 am Aaron Peeler wrote: > Sounds good - lets do it. > > 'systemuser' as a name works for me. I can't think of any conflicts. > > Aaron > > > > --On March 5, 2009 11:11:30 AM -0500 Josh Thompson > > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Tue March 3 2009 10:00:03 am Andy Kurth wrote: > >> > In working on the API for block reservations (VCL-78), I've realized > >> > there needs to be an owner for any block reservations created via the > >> > API. Additionally, when the backend uses the API to process an > >> > existing block reservation, it will need to use some userid to > >> > authenticate. Should we create a new user for such tasks in addition > >> > to the vclreload user? Should we rename the vclreload user? Should we > >> > just keep using the vclreload user for any system based tasks and just > >> > keep the name even though it doesn't reflect the use? > >> > >> I'm not familiar with how the XML RPC API stuff works so bear with me > >> and correct me if I'm reading things incorrectly. The backend provides > >> credentials in order to use the XML RPC API. Is vclreload being used > >> for this? > > > > Actually, the backend isn't using the XML RPC API for anything right now. > > For the block reservation API that I'm currently working on (and for > > anything else in the future), I think whatever we determine in this > > thread should be used as the account with which the backend > > authenticates to the frontend. > > > >> I understand the next step when the backend asks the API to generate > >> reload requests for a given blockrequest/blocktime. The reload requests > >> each need to have a user assigned to them, currently vclreload. > > > > Correct. > > > > - From what Aaron said in his response about the number of locations > > vclreload is used in the backend code, it sounds like renaming it to > > something like 'systemuser' would not be too difficult. We'd need to > > create a JIRA issue for it and coordinate working on that issue on the > > frontend, database, and backend all at the same time. > > > > How does that sound? > > > > Josh > > - -- > > - --- > > Josh Thompson > > Systems Programmer > > Virtual Computing Lab (VCL) > > North Carolina State University > > > > josh_thomp...@ncsu.edu > > 919-515-5323 > > > > my GPG/PGP key can be found at www.keyserver.net > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.9 (GNU/Linux) > > > > iD8DBQFJr/m2V/LQcNdtPQMRAo5HAJ9D+CuXoDx8dI0A7Pl78O2Y2LQ7RgCfXoT9 > > bMeypAsQ1uwNNpr0kqAqfWg= > > =uheL > > -END PGP SIGNATURE- > > Aaron Peeler > OIT Advanced Computing > College of Engineering-NCSU > 919.513.4571 > http://vcl.ncsu.edu - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJsAN0V/LQcNdtPQMRAlYwAJwNfV9sB5N9Ort67LRbpOat3FNJFACffRpw vWAL8jMjWYmRwxQ3uqFvyfg= =k5K+ -END PGP SIGNATURE-
Re: another user for system tasks?
Sounds good - lets do it. 'systemuser' as a name works for me. I can't think of any conflicts. Aaron --On March 5, 2009 11:11:30 AM -0500 Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue March 3 2009 10:00:03 am Andy Kurth wrote: > In working on the API for block reservations (VCL-78), I've realized > there needs to be an owner for any block reservations created via the > API. Additionally, when the backend uses the API to process an existing > block reservation, it will need to use some userid to authenticate. > Should we create a new user for such tasks in addition to the vclreload > user? Should we rename the vclreload user? Should we just keep using > the vclreload user for any system based tasks and just keep the name > even though it doesn't reflect the use? I'm not familiar with how the XML RPC API stuff works so bear with me and correct me if I'm reading things incorrectly. The backend provides credentials in order to use the XML RPC API. Is vclreload being used for this? Actually, the backend isn't using the XML RPC API for anything right now. For the block reservation API that I'm currently working on (and for anything else in the future), I think whatever we determine in this thread should be used as the account with which the backend authenticates to the frontend. I understand the next step when the backend asks the API to generate reload requests for a given blockrequest/blocktime. The reload requests each need to have a user assigned to them, currently vclreload. Correct. - From what Aaron said in his response about the number of locations vclreload is used in the backend code, it sounds like renaming it to something like 'systemuser' would not be too difficult. We'd need to create a JIRA issue for it and coordinate working on that issue on the frontend, database, and backend all at the same time. How does that sound? Josh - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJr/m2V/LQcNdtPQMRAo5HAJ9D+CuXoDx8dI0A7Pl78O2Y2LQ7RgCfXoT9 bMeypAsQ1uwNNpr0kqAqfWg= =uheL -END PGP SIGNATURE- Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu
Re: frontend API for block reservations (VCL-78)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu February 5 2009 10:18:17 am Josh Thompson wrote: > > > function name: XMLRPCblockAllocation > > > > > > parameters: > > > imageid - id of the image to be used > > > start - unix timestamp for the start time (i.e. machines should be > > > prep'd and ready by this time) > > > end - unix timestamp for the end time > > > machinecount - number of computers to allocate > > > usergroupid - id of user group for checking user access to machines > > > ignoreprivileges - 0 (false) or 1 (true) - set to 1 to select > > > computers from any that are mapped to be able to run the image; set to > > > 0 to only select computers from ones that are both mapped and that > > > users in usergroupid have been granted access to through the privilege > > > tree. If this is set to 1, usergroupid is ignored (more on this > > > below). After coding this, I discovered I converted 'start' and 'end' to the mysql datetime format and never used the unix timestamp format. Does anyone see any reason to keep the parameters as unix timestamps? If not, I'll specify that they should be mysql datetime format. I'm think that would be easier for people to build when calling the API than a unix timestamp. Josh - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJr/s1V/LQcNdtPQMRAiMpAJ93GkRA/1jJj0k+X0afyp9I92g0zwCdHDNj SgWB7+f1ZJ6QO+43IdiSCCM= =LvnQ -END PGP SIGNATURE-
Re: another user for system tasks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue March 3 2009 10:00:03 am Andy Kurth wrote: > > In working on the API for block reservations (VCL-78), I've realized > > there needs to be an owner for any block reservations created via the > > API. Additionally, when the backend uses the API to process an existing > > block reservation, it will need to use some userid to authenticate. > > Should we create a new user for such tasks in addition to the vclreload > > user? Should we rename the vclreload user? Should we just keep using the > > vclreload user for any system based tasks and just keep the name even > > though it doesn't reflect the use? > > I'm not familiar with how the XML RPC API stuff works so bear with me and > correct me if I'm reading things incorrectly. The backend provides > credentials in order to use the XML RPC API. Is vclreload being used for > this? Actually, the backend isn't using the XML RPC API for anything right now. For the block reservation API that I'm currently working on (and for anything else in the future), I think whatever we determine in this thread should be used as the account with which the backend authenticates to the frontend. > I understand the next step when the backend asks the API to generate reload > requests for a given blockrequest/blocktime. The reload requests each need > to have a user assigned to them, currently vclreload. Correct. - From what Aaron said in his response about the number of locations vclreload is used in the backend code, it sounds like renaming it to something like 'systemuser' would not be too difficult. We'd need to create a JIRA issue for it and coordinate working on that issue on the frontend, database, and backend all at the same time. How does that sound? Josh - -- - --- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at www.keyserver.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJr/m2V/LQcNdtPQMRAo5HAJ9D+CuXoDx8dI0A7Pl78O2Y2LQ7RgCfXoT9 bMeypAsQ1uwNNpr0kqAqfWg= =uheL -END PGP SIGNATURE-
