Re: VirtualBox provisioning and capture.
Hi David, Sorry it's taken so long to get this tested. I was able to set it up to work with our current code base without too much effort, which is good. Not sure if it was intended or if I set it up wrong, but I ran into a small issue with trying to provision a non-imaging load. Around line 356 when adding the storage medium I couldn't get it to work without explicitly listing the hdd file. --medium $image_repository_path/$requestedimagename, root) my edit: --medium $image_repository_path/$requestedimagename/$requestedimagename.vdi, root) Overall it works and looks really good and I think we can go ahead and add it to the repository. Then it will be easier to maintain it and make any improvements. I'll go ahead and add it to the repository today. Since you have the ICLA on file, you're interested in becoming a committer, and have shown that you can add great value to the community, we'll start the next phase, which is a voting process with the mentors and current committers. Aaron On 12/15/10 4:31 PM, David Hutchins wrote: Thanks for the info, I will make those changes to the module. On Wed, Dec 15, 2010 at 4:23 PM, Andy Kurthandy_ku...@ncsu.edu wrote: Thanks for contributing this. I took a quick look at it. The utils.pm patch can be avoided by changing the call from _getcurrentimage to $self-os-get_current_image_name(). The OS.pm::get_current_image_name subroutine takes its place and should return the same value. All calls to utils.pm::_getcurrentimage should really be changed and this subroutine should be removed. It contains code that was used before the OS-specific code was modularized. -Andy On 12/10/2010 8:34 AM, Aaron Peeler wrote: Cool. Look forward to testing it out. Thanks -Aaron On 12/9/10 5:26 PM, David Hutchins wrote: Provisioning and capture are working. The module only supports localdisk mode at the moment, but network storage support should be trivial at this point. If anyone wants to test this, feel free to contact me with questions. The code is currently attached to JIRA issue VCL-417, at https://issues.apache.org/jira/browse/VCL-417 . vcl.pm will have to be patched with the two patches, provisioning patch then capture patch. and utils.pm will need the provided patch. -- Aaron Peeler Program Manager Virtual Computing Lab NC State University aaron_pee...@ncsu.edu 919-513-4571
Re: VirtualBox provisioning and capture.
Thanks Aaron, That was an issue I was aware of, in my setup I just have all the disk images in the root of the repository. I had planned to fix that, but never got around to it, and being caught up in the migration of our finance system to another product I haven't been able to work on VCL here for a couple months. There is a light at the end of the tunnel though, and I expect to get back to this soon. I had seen a JIRA issue with a request for persistent snapshotting, and had started on that code last time I was working on it. Since VBox creates a snapshot by default when provisioning, the thought was to just unregister and move that SS image to a /snapshots directory in the repository and insert a record into a newly created table on the management DB with the location, owner, UUID, image that the SS works against, etc. Then add an extra drop down from the create reservation page that appears and gets populated if the user selects an image that they have snapshots against. Of course there would need to be some sort of cleanup processes that would clear out SS images if unused for some predefined length of time and such. Thanks again: -David On Thu, Feb 3, 2011 at 9:32 AM, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi David, Sorry it's taken so long to get this tested. I was able to set it up to work with our current code base without too much effort, which is good. Not sure if it was intended or if I set it up wrong, but I ran into a small issue with trying to provision a non-imaging load. Around line 356 when adding the storage medium I couldn't get it to work without explicitly listing the hdd file. --medium $image_repository_path/$requestedimagename, root) my edit: --medium $image_repository_path/$requestedimagename/$requestedimagename.vdi, root) Overall it works and looks really good and I think we can go ahead and add it to the repository. Then it will be easier to maintain it and make any improvements. I'll go ahead and add it to the repository today. Since you have the ICLA on file, you're interested in becoming a committer, and have shown that you can add great value to the community, we'll start the next phase, which is a voting process with the mentors and current committers. Aaron On 12/15/10 4:31 PM, David Hutchins wrote: Thanks for the info, I will make those changes to the module. On Wed, Dec 15, 2010 at 4:23 PM, Andy Kurthandy_ku...@ncsu.edu wrote: Thanks for contributing this. I took a quick look at it. The utils.pm patch can be avoided by changing the call from _getcurrentimage to $self-os-get_current_image_name(). The OS.pm::get_current_image_name subroutine takes its place and should return the same value. All calls to utils.pm::_getcurrentimage should really be changed and this subroutine should be removed. It contains code that was used before the OS-specific code was modularized. -Andy On 12/10/2010 8:34 AM, Aaron Peeler wrote: Cool. Look forward to testing it out. Thanks -Aaron On 12/9/10 5:26 PM, David Hutchins wrote: Provisioning and capture are working. The module only supports localdisk mode at the moment, but network storage support should be trivial at this point. If anyone wants to test this, feel free to contact me with questions. The code is currently attached to JIRA issue VCL-417, at https://issues.apache.org/jira/browse/VCL-417 . vcl.pm will have to be patched with the two patches, provisioning patch then capture patch. and utils.pm will need the provided patch. -- Aaron Peeler Program Manager Virtual Computing Lab NC State University aaron_pee...@ncsu.edu 919-513-4571
Re: VirtualBox provisioning and capture.
No problem - I understand getting pulled into other tasks. Thanks for the additional info on the plans, those sound good. We can also help the design to line up with some useful general error checking in the VMware/* modules. Also we are interested in taking advantage of several features of vbox. I've committed the vbox.pm module and the changes to vcl.sql file into the repository - anyone who wants to play with it can pull it from there. The two changes in the sql file where to add vbox to the module and provisioning tables - which will be needed for it to work. I tagged it with the jira issue - https://issues.apache.org/jira/browse/VCL-417 Aaron On 2/3/11 10:00 AM, David Hutchins wrote: Thanks Aaron, That was an issue I was aware of, in my setup I just have all the disk images in the root of the repository. I had planned to fix that, but never got around to it, and being caught up in the migration of our finance system to another product I haven't been able to work on VCL here for a couple months. There is a light at the end of the tunnel though, and I expect to get back to this soon. I had seen a JIRA issue with a request for persistent snapshotting, and had started on that code last time I was working on it. Since VBox creates a snapshot by default when provisioning, the thought was to just unregister and move that SS image to a /snapshots directory in the repository and insert a record into a newly created table on the management DB with the location, owner, UUID, image that the SS works against, etc. Then add an extra drop down from the create reservation page that appears and gets populated if the user selects an image that they have snapshots against. Of course there would need to be some sort of cleanup processes that would clear out SS images if unused for some predefined length of time and such. Thanks again: -David On Thu, Feb 3, 2011 at 9:32 AM, Aaron Peeleraaron_pee...@ncsu.edu wrote: Hi David, Sorry it's taken so long to get this tested. I was able to set it up to work with our current code base without too much effort, which is good. Not sure if it was intended or if I set it up wrong, but I ran into a small issue with trying to provision a non-imaging load. Around line 356 when adding the storage medium I couldn't get it to work without explicitly listing the hdd file. --medium $image_repository_path/$requestedimagename, root) my edit: --medium $image_repository_path/$requestedimagename/$requestedimagename.vdi, root) Overall it works and looks really good and I think we can go ahead and add it to the repository. Then it will be easier to maintain it and make any improvements. I'll go ahead and add it to the repository today. Since you have the ICLA on file, you're interested in becoming a committer, and have shown that you can add great value to the community, we'll start the next phase, which is a voting process with the mentors and current committers. Aaron On 12/15/10 4:31 PM, David Hutchins wrote: Thanks for the info, I will make those changes to the module. On Wed, Dec 15, 2010 at 4:23 PM, Andy Kurthandy_ku...@ncsu.edu wrote: Thanks for contributing this. I took a quick look at it. The utils.pm patch can be avoided by changing the call from _getcurrentimage to $self-os-get_current_image_name(). The OS.pm::get_current_image_name subroutine takes its place and should return the same value. All calls to utils.pm::_getcurrentimage should really be changed and this subroutine should be removed. It contains code that was used before the OS-specific code was modularized. -Andy On 12/10/2010 8:34 AM, Aaron Peeler wrote: Cool. Look forward to testing it out. Thanks -Aaron On 12/9/10 5:26 PM, David Hutchins wrote: Provisioning and capture are working. The module only supports localdisk mode at the moment, but network storage support should be trivial at this point. If anyone wants to test this, feel free to contact me with questions. The code is currently attached to JIRA issue VCL-417, at https://issues.apache.org/jira/browse/VCL-417 . vcl.pm will have to be patched with the two patches, provisioning patch then capture patch. and utils.pm will need the provided patch. -- Aaron Peeler Program Manager Virtual Computing Lab NC State University aaron_pee...@ncsu.edu 919-513-4571 -- Aaron Peeler Program Manager Virtual Computing Lab NC State University aaron_pee...@ncsu.edu 919-513-4571
Incubator PMC/Board report for February 2011 (vcl-dev@incubator.apache.org)
Dear VCL Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 16 February 2011, 10 am Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/February2011 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Fwd: Incubator report reminders sent for February 2011
It's our turn to participate in the Incubator report. :) Regards, Alan Begin forwarded message: From: no-re...@apache.org Date: February 1, 2011 6:00:14 AM PST To: priv...@incubator.apache.org Subject: Incubator report reminders sent for February 2011 Reply-To: priv...@incubator.apache.org The next board meeting is scheduled for Wed, 16 February 2011, 10 am Pacific. I have just sent reminder emails to these addresses, requesting them to supply board reports one week before the above date: Amber Developers amber-...@incubator.apache.org Bluesky Developers bluesky-...@incubator.apache.org Celix Developers celix-...@incubator.apache.org Clerezza Developers clerezza-...@incubator.apache.org Deltacloud Developers deltacloud-...@incubator.apache.org Droids Developers droids-...@incubator.apache.org EasyAnt Developers gene...@incubator.apache.org HISE Developers hise-...@incubator.apache.org Jena Developers jena-...@incubator.apache.org Kitty Developers kitty-...@incubator.apache.org Libcloud Developers libcl...@incubator.apache.org Mesos Developers mesos-...@incubator.apache.org NPanday Developers npanday-...@incubator.apache.org Nuvem Developers nuvem-...@incubator.apache.org OpenNLP Developers opennlp-...@incubator.apache.org PhotArk Developers photark-...@incubator.apache.org SIS Developers sis-...@incubator.apache.org Stanbol Developers stanbol-...@incubator.apache.org Stonehenge Developers stonehenge-...@incubator.apache.org VCL Developers vcl-dev@incubator.apache.org Wave Developers wave-...@incubator.apache.org Whirr Developers whirr-...@incubator.apache.org Wink Developers wink-...@incubator.apache.org Wookie Developers wookie-...@incubator.apache.org Zeta Components Developers zeta-...@incubator.apache.org Marvin - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org
[jira] Created: (VCL-432) imaging and long-term reservations
imaging and long-term reservations -- Key: VCL-432 URL: https://issues.apache.org/jira/browse/VCL-432 Project: VCL Issue Type: Bug Components: vcld (backend) Affects Versions: 2.3 Reporter: Aaron Peeler Improve the imaging reservations - Automatically start the image capture process when a reservation reaches the end-time for both imaging reservations and long-term reservations. This will provide a way for image creators not to loose any work due to the reservation expiring. The initial steps would be at the end time, instead of timing out, send a notice to the user. Automatically start the image by inserting either a new image/imagerevision or updating the version number in imagerevision. If new name the image in some format yet to be determined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (VCL-432) imaging and long-term reservations
[ https://issues.apache.org/jira/browse/VCL-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Peeler updated VCL-432: - Issue Type: Improvement (was: Bug) imaging and long-term reservations -- Key: VCL-432 URL: https://issues.apache.org/jira/browse/VCL-432 Project: VCL Issue Type: Improvement Components: vcld (backend) Affects Versions: 2.3 Reporter: Aaron Peeler Improve the imaging reservations - Automatically start the image capture process when a reservation reaches the end-time for both imaging reservations and long-term reservations. This will provide a way for image creators not to loose any work due to the reservation expiring. The initial steps would be at the end time, instead of timing out, send a notice to the user. Automatically start the image by inserting either a new image/imagerevision or updating the version number in imagerevision. If new name the image in some format yet to be determined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
