-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Norma,
To unsubscribe, send a blank email to [email protected] from the email address you used to subscribe to the list. The unsubscribe link for all ASF lists is in the headers of the email. Josh On Friday, October 31, 2014 6:22:57 AM Norma P Estrella wrote: > Remove me please > > Norma P. Estrella, xoxo > Sent from my iPhone > > On Oct 31, 2014, at 6:14 AM, Josh Thompson <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I'd like to either close VCL-710 (Allow an admin to permanently delete an > > image) as Won't Fix, or bump it to a later release. The ability to delete > > VMware image files has been added to the setup part of vcld. I imagine > > adding other types of image files wouldn't be too difficult. There is > > currently no way for the frontend to trigger something like this on the > > backend. So, it would require enough design and development that I don't > > think it is a good idea to try to get it in 2.4. > > > > Josh > > > > On Tuesday, October 21, 2014 4:26:46 PM Aaron Peeler wrote: > >> VCL-170 is completed on the backend and in the database sql files. So > >> it can be marked fixed. > >> Aaron > >> > >> On Tue, Oct 21, 2014 at 3:26 PM, Josh Thompson <[email protected]> > > > > wrote: > >>> -----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+t > >>>> es > >>>> t+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----- > > > > - -- > > - ------------------------------- > > 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) > > > > iEYEARECAAYFAlRTizYACgkQV/LQcNdtPQPNpQCeKNg38EIKXB6xIiqlCyeDmfcr > > ZGgAnAjQMqcUlQ/3yWMPT9Ev3yzzqMj+ > > =Mtur > > -----END PGP SIGNATURE----- - -- - ------------------------------- 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) iEYEARECAAYFAlRTkyMACgkQV/LQcNdtPQOKGwCeOiTPvu67rsWKXPa/FhtLugdZ 7CoAn0Uz6Zaz/YiDyNOSCDWrP0oSBAJE =pecQ -----END PGP SIGNATURE-----
