FYI: I located what was going on with VMware + managed storage. It looks like there was a feature that went in (at some point…not sure when) that added the ability to resize a root disk (so it doesn’t have to be the same size as the template it uses) when spinning up a VM. That code triggered an exception with managed storage because it was appending an extra “.vmdk” on to the file name (so the VMDK file couldn’t be located in the datastore). I have corrected the problem and pushed a second commit to PR 2141.
https://github.com/apache/cloudstack/pull/2141 If we’d like this targeted against master, let me know. Thanks! Mike On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: this is why i say we should branch on first RC, fix in release branch only and merge forward On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <williamstev...@gmail.com> wrote: > I know it is hard to justify not merging PRs that seem ready but are not > blockers in an RC, but it is a vicious circle which ultimately results in a > longer RC process. > > It is something i struggled with as a release manager as well. > > On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org> wrote: > > Thanks Mike, > > Will hold off next RC until we hear an update from you. > > Regarding merging non-blockers, unfortunately, its a side-effect > of taking more than three months in the RC phase :( > > Thanks, > > ~ Rajani > > http://cloudplatform.accelerite.com/ > > On June 13, 2017 at 10:10 AM, Tutkowski, Mike > (mike.tutkow...@netapp.com) wrote: > > Hi everyone, > > I had a little time this evening and re-ran some VMware-related > tests around managed storage. I noticed a problem that I’d like > to investigate before we spin up the next RC. Let’s hold off on > the next RC until I can find out more (I should know more within > 24 hours). > > Thanks! > Mike > > On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl> > wrote: > >> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike" > <mike.tutkow...@netapp.com>: >> >> >> Hi, >> >> I opened a PR against the most recent RC: > https://github.com/apache/cloudstack/pull/2141 >> >> I ran all managed-storage regression tests against it and they > pass (as noted in detail in the PR). >> >> If someone wants to take this code and create a new RC from > it, I’m +1 on the new RC as long as this is the only commit added > to it since the current RC. > > Thanks Mike! > > If this PR is good we should probably merge it asap and go for > RC5. > > 4.10 should really be released by now. > > Wido > >> >> Thanks! >> Mike >> >> On 6/9/17, 7:43 PM, "Tutkowski, Mike" > <mike.tutkow...@netapp.com> wrote: >> >> Hi everyone, >> >> I found a critical issue that was introduced into this RC > since the most recent RC, so I am -1 on this RC. >> >> The fix for this ticket breaks the support for storing volume > snapshots on primary storage (which is a feature managed storage > can support): >> >> https://issues.apache.org/jira/browse/CLOUDSTACK-9685 >> >> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e >> >> At a high level, what it does is remove a row from the > cloud.snapshot_store_ref table when a volume is deleted that has > one or more volume snapshots. >> >> This is fine for non-managed (traditional) storage; however, > managed storage can store volume snapshots on primary storage, so > removing this row breaks that functionality. >> >> I can fix the problem that this commit introduced by looking > at the primary storage that supports the volume snapshot and > checking the following: 1) Is this managed storage? 2) If yes, is > the snapshot in question stored on that primary storage? >> >> The problem is I will be out of the office for a couple weeks > and will not be able to address this until I return. >> >> We could revert the commit, but I still will not have time to > run the managed-storage regression test suite until I return. >> >> On a side note, it looks like this commit was introduced since > the most recent RC. I would argue that it was not a blocker and > should not have been placed into the new RC. We (as a community) > tend to have a lot of code go in between RCs and that just > increases the chances of introducing critical issues and thus > delaying the release. We’ve gotten better at this over the years, > but we should focus more on only allowing the entry of new code > into a follow-on RC that is critical (or so trivial as to not at > all be likely to introduce any problems…like fixing an error > message). >> >> Thanks for your efforts on this, everyone! >> Mike >> >> On 6/9/17, 8:52 AM, "Tutkowski, Mike" > <mike.tutkow...@netapp.com> wrote: >> >> Hi Rajani, >> >> I will see if I can get all of my managed-storage testing > (both automated and manual) done today. If not, we’ll need to see > if someone else can complete it before we OK this RC as I won’t > be back in the office for a couple weeks. I’ll report back later > today. >> >> Thanks, >> Mike >> >> On 6/9/17, 2:34 AM, "Rajani Karuturi" <raj...@apache.org> > wrote: >> >> Yup. thats right. I dont know how it happened but, it created >> from the previous RC commit. The script is supposed to do a > git >> pull. I didn't notice any failures. Not sure what went wrong. >> >> Thanks for finding it mike. I am creating RC4 now and > cancelling >> this. >> >> ~ Rajani >> >> http://cloudplatform.accelerite.com/ >> >> On June 9, 2017 at 12:07 PM, Tutkowski, Mike >> (mike.tutkow...@netapp.com) wrote: >> >> Hi Rajani, >> >> I don’t see the following PR in this RC: >> >> https://github.com/apache/cloudstack/pull/2098 >> >> I ran all of my managed-storage regression tests. They all >> passed with the exception of the one that led to PR 2098. >> >> As I examine the RC in a bit more detail, it sits on top of >> ed2f573, but I think it should sit on top of ed376fc. >> >> As a result, I am -1 on the RC. >> >> It takes me about a day to run all of the managed-storage >> regression tests and I am out of the office for the next > couple >> weeks, so I’d really like to avoid another RC until I’m back > and >> able to test the next RC. >> >> Thanks! >> Mike >> >> On 6/7/17, 4:36 AM, "Rajani Karuturi" <raj...@apache.org> > wrote: >> >> Hi All, >> >> I've created 4.10.0.0 release with the following artifacts up >> for a vote: >> >> Git Branch and Commit SH: >> > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h= > a55738a31d0073f2925c6fb84bf7a6bb32f4ca27 >> Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27 >> Branch: 4.10.0.0-RC20170607T1407 >> >> Source release (checksums and signatures are available at the >> same >> location): >> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/ >> >> SystemVm Templates: >> http://download.cloudstack.org/systemvm/4.10/RC3/ >> >> PGP release keys (signed using CBB44821): >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >> >> Vote will be open for 72 hours. >> >> For sanity in tallying the vote, can PMC members please be > sure >> to indicate >> "(binding)" with their vote? >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> Thanks, >> ~Rajani >> http://cloudplatform.accelerite.com/ >> >> >> >> >> -- Daan
