-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What's the status of the backend development on the following issues?
VCL-170 - option to power off blades after reservation - new reload module Computers can be configured to have their Predictive Loading Module set to "Unload Post reservation" now. So, I think the frontend work on this is done. VCL-174 - NAT - support for sites that have small IP address ranges Frontend work for this is mostly done. I just need to add something to the parts of the site where computers and management nodes are managed to be able to set them as NAT hosts or not. VCL-253 - Allow users to specify RDP port Users can specify an alternate port for RDP under User Preferences now. It only overrides when a connect method has "remote desktop" or "rdp" in the name and is using tcp port 3389 as the port. VCL-568 - refresh current reservations page 15 minutes after a reservation becomes available At some point, the plan here was to key off of an entry in the computerloadlog being added once a node was deployed and ready for user connection. That gave the frontend a time from which to start counting down to later be able to refresh the page in case of reservation timeout. However, there doesn't appear to be an entry being inserted in computerloadlog right after the reservation becomes ready. There also needs to be a similar entry for when the user first clicks the Connect button. VCL-571 - EC2 API provisioning module Has any work been done on incorporating this contribution? I'm not sure what changes would need to be done of the frontend for it. VCL-584 - Extend features of Server loads Are the two items left in this issue finished in the backend? Andy - I haven't been able to reproduce the problem you saw that you listed in your comment on this issue. I did modify things so that request.forimaging does not get updated for checkpoints. Josh On Friday, October 17, 2014 6:45:33 PM Andy Kurth wrote: > I was hoping this thread would generate more discussion and help facilitate > completing the VCL 2.4 release. Thank you Josh for providing your updates > and comments. Is anyone else working on anything related to 2.4? If so, > please share. > > I have an update on the development issues I have been working on below. > Before getting into that, there are some more general topics which need to > be managed. > > 1) Testing. We don't have any sort of documented test plan, test cases, a > checklist, nothing... We don't have adequate instructions regarding how to > set up a test environment based off of the code from trunk or a release > artifact. We don't have any information what what and how to test. These > is critically needed. Is anyone willing to help to work out and document > these processes? There is a lot of helpful information available on other > ASF project sites. Here's a good example: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+p > rocedure > > Please take a look at this page. The first paragraph applies to all ASF > projects and is something that everyone needs to understand. > (Quoted from cloudstack's site) > > > For an apache project, a VOTE on a release candidate is a very important > > process. By voting (particularly for PPMC members and committers), you > > are > > saying to the world that "yes, I have download, verified and tested using > > the project's procedure for testing". Your +1, 0 or -1 vote is an > > indication of the success of the steps listed. > > In the past when a vote for a VCL release was started, there was a flurry > of +1's from people who had not communicated on the dev list about anything > having to do with the release. I could be wrong, but I'm guessing some > people who voted +1 did not test the release artifact in any way. Not > having any documentation on how one would do this leads me to this > conclusion. > > Documenting how to set up a test environment needs to be done ASAP and can > be done concurrently with the remaining code development. Is anyone > willing to take a stab at starting this? I'd be happy to help, but really > want to focus on finishing up the development items I'm working on. > > 2) Documentation. With every release comes a spike in interest. People > are interested in what has been fixed/improved and what new features have > been added. They then look at the accompanying documentation. It would be > a shame if someone got a bad impression and became frustrated due to poor > documentation. There are new features with this release and things have > been dramatically reorganized on the VCL website portal. We need to make > sure documentation is adequate and anything which refers to things that > have changed gets updated. I'm not suggesting that we need to rework all > of the existing documentation or fill in all of the holes, but there is > obviously work that needs to be done prior to the release. Is anyone > willing to manage this? > > Update on the issues I have been working on, I hope to have these done next > week: > > VCL-764: Database changes for VCL 2.4 > The tricky parts are done. I have code which parses a reference .sql file > (the 2.4 schema in this case), retrieves the current schema definition > information from the database, and can compare the two. It then sorts out > all of the operations that need to be done and then can make the changes to > update the current database. I'm thinking for this release the > instructions for installing the database for a fresh install can remain the > same, although the script could automate some additional steps in the > future. Upgrades can use the new script and execute it from an existing > management node. I added some other features to the script which made > development and testing easier. It can download the schema for any of the > previous releases, create a temporary test database, and then upgrade the > test database with the reference (2.4) schema. The script will have a menu > system based off of how "vcld -setup" works. I need to finish implementing > this and polish it up. > > VCL-685: VMware improvements for VCL 2.4 > I didn't plan on spending much more time on the VMware code but there were > some problems which needed to be addressed. We have been seeing a lot of > problems lately with our old ESXi 4.1 hosts. The code was modified to make > it more resilient and for some problems, self healing. See the commit > comments for the details. > > VCL-767: Allow dynamic private IP addresses, remove /etc/hosts requirement > This needs to be finished. I spoke to Young Oh today, partially regarding > this. The code changes shouldn't take too much time. I have already > written a "vcld -setup" option which gathers all of the computers > controlled by a management node, checks the private IP address each > computer's hostname resolves to, and verifies/updates the private IP > address in the computers table. I just need to update all the places still > using the hostname to SSH into the computers. > > VCL-753: Improve user connection checking and how firewall is locked down > I'm thinking this issue should be bumped for the sake of time and quality. > It will provide a much more secure way of handling how the firewall is > locked down, but is also very complicated and could introduce problems > until all the bugs are worked out. The current code which this will > replace is stable. Untag from 2.4? Everyone agree? > > VCL-783: Add support for 64-bit cygwin > Again, this should be quick. > > > I did not include the previous quoted messages in this reply since they > were pruned in some replies based on what the reply was referring to. As a > result, they would have been incomplete without some manual reassembly. > Here's a link to the entire thread for reference: > http://vcl.markmail.org/thread/jwcwymumnxxpd5ns > > Thank You, > Andy - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRGs08ACgkQV/LQcNdtPQPXUQCggCE0e4mN5r1z56QIRWp7QZAo uiIAn2hCX7aTwCnbO94j+3ORqDZwWYlp =EIkC -----END PGP SIGNATURE-----
