-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy - thanks for the update. More inline...
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. +1 on having documentation for how to set up a test environment. Like Andy, I'm trying to get through a number of remaining issues on the frontend. So, it would be great if someone would be willing to step up and take a stab at this. Those of use that have been around longer would certainly be willing to help polish it up. > 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? This is a great point. > 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? I'd really like to see this get added in. However, I think we're to the point that trimming anything we can to get a release out is a good idea. So, I'm okay for it to be untagged for 2.4. For the following release, it would be great to just pick a few key issues to focus on instead of the large number we've done for this one. Josh > 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) iEYEARECAAYFAlRFD58ACgkQV/LQcNdtPQP16ACdFMcVsjO5hJR2xIMzs1Lf4FHH 0G4AnjISF1SKFQKkj8aFWnJQnmW65+cw =I3dN -----END PGP SIGNATURE-----
