Test case 3 and 4 wording has been changed, see below. On Oct 22, 2012, at 6:34 PM, "Musayev, Ilya" <imusa...@webmd.net> wrote:
> Following issues has been witnessed thus far: > > I'm just going to provide the output of my tests and you be the judge if it's > bug or an error on my part - I can then submit a bug report if needed. > > 1 - when configuring VMware ESXi environment initially primary store cannot > be set as VMFS and must be configured as NFS for setup to work. I could not > get VMFS to work as primary storage without adding NFS as primary first. > (need to confirm if VMFS will still works as primary - post adding NFS as > primary - as of now I just use NFS as primary storage) > > 2 - if VMFS LUN is incorrectly set while going through initial setup process > (not using first time wizard - since VMware ESXi Cluster is not an option) > and user mistakenly enters improper LUN, the UI will detect as an error but > even if you correct it - there is no way to continue the setup process and no > API calls are issued to confirm the validity of the new LUN name. at this > point, I had to start over from scratch. > > 3. Don't know if this would-be a bug or feature enhacement. While adding a > vmware cluster - the CS is specifically looking for "Management Network" port > group on vSwitch0. If name does not match - you could see an error that > "Management Network" portgroup is not found. The prefered logic would be to > lookup the portgroup of vmk0 (or whatever management virtual NIC is) and use > it as your portgroup. > > 4. If your VMware cluster has virtual switch vSwitch0 used for outbound > network communication and another vSwitch1 for other internal private tasks > with no outbound network connectivity - when the Secondary storage VM is > deployed it incorrectly picks vSwitch1 and attempts to use this vswitch for > communication with CS core. Obviously fails since no NICs are connected to > vSwitch1. > > 5. This seems to have been the case for me all the time - but by default - > the first time wizard does not have VMware cluster as an option. I always to > choose 'Skip, I've used cloud stack before' button. > > 6. If I attempt to do a complete cleanup without flushing DB, I'm unable to > delete physical network connection - eventhough no networks are > defined/assigned - and therefore I cannot delete the zone. I had to drop > mysql db and start fresh. > > 7. The cloud ssh and password scripts still need a bit more enhancement - I > will submit the patch shortly. I also think we can do more improvements on > the way code is written without changing functionality. > > * None of these are show stoppers - but things I've noticed when I went > through install process. At the end, I was able to get it to work. > > Let me know which are bugs and I will file a bug report with supporting > documentation. > > I will go through install process once more next week or later this week to > double check and note all the issues. I will also be testing Netscaler > integration. > > Regards > Ilya > > > > On Oct 22, 2012, at 12:17 PM, "Chip Childers (ASF)" <chipchild...@apache.org> > wrote: > >> Hi All, >> >> I would like to call a vote for Apache CloudStack (Incubating) Release >> 4.0.0-incubating (third round). >> >> We encourage the whole community to download and test these release >> artifacts, so that any critical issues can be resolved before the >> release is made. The more time that each individual spends reviewing >> the artifacts, the higher confidence we can have in both the release >> itself and our ability to pass an IPMC vote later on. Everyone is free >> to vote on this release, so please give it a shot. >> >> Instructions for Validating and Testing the artifacts can be found here: >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure >> >> If you have any trouble setting up a test environment using the >> procedure above, please ask on the cloudstack-dev@i.a.o list. Someone >> will be sure to help, and we'll improve our test procedure >> documentation at the same time! >> >> Now, on to the specifics of what we are voting on... >> >> >> The following artifacts are up for the vote: >> http://people.apache.org/~chipchilders/dist/cloudstack/releases/4.0.0-incubating/ >> >> PGP release keys (signed using A99A5D58): >> http://people.apache.org/~chipchilders/dist/cloudstack/KEYS >> >> Branch: 4.0 >> Commit: 6355965dcd956811dd471a9d03c73dadcf68f480 >> >> >> List of changes: >> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=CHANGES;hb=refs/heads/4.0 >> >> The artifacts being voted on during this round also include the >> following additional fixes (most were identified as part of testing >> during the last round of voting): >> >> * Many documentation fixes (particularly the release notes and >> installation guide) >> * CLOUDSTACK-341: Failing to display Management Traffic Details on the UI >> * CLOUDSTACK-349: Russian l10n not properly displaying >> * Correction to the devcloud rdeploy build target, to make testing easier >> * CLOUDSTACK-363: Upgrades from 2.2.14, 3.0.2 to the Current build will fail >> * CLOUDSTACK-118: Status of host resorce stuck in "ErrorInMaintenance" >> * DISCLAIMER added to the Marvin tool dir >> >> >> The vote will be open for 72 hours. >> >> >> For sanity in tallying the vote, can PPMC and IPMC members please be >> sure to indicate "(binding)" with their vote? >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> Thanks! >> > >
