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

Reply via email to