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+procedure 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
