Min Chen <min.chen@...> writes: > > Agree with Edison on this regarding priority. I can see more influence of CloudStack if we can support > upgrade from NFS to S3. We didn't say that we are not supporting upgrade path for S3 from 4.0 to 4.2, just can > be prioritized lower than upgrading from NFS to S3 to gain more user base. > > Thanks > -min > > From: Edison Su <Edison.su@...<mailto:Edison.su@...>> > Reply-To: > "dev@...<mailto:dev@...>" <dev <at> cloudstack.apache.org<mailto:dev@...>> > Date: Friday, July 26, 2013 11:02 AM > To: > "dev@...<mailto:dev@...>" <dev <at> cloudstack.apache.org<mailto:dev@...>> > Subject: [ACS42] Duplicate S3 and Swift Object Storage Features > > “I see prodded a facility to convert NFS secondary storage to object storage as an enhancement where the > lack of a migration path is a blocking defect.” > I have different view on this item, regarding the priority. At one hand, we have almost all of cloudstack > users are using NFS as secondary storage, if there is no way to upgrade to S3, then all of existing > CloudStack deployment can’t upgrade to use your Basho CS, or Amazon S3. On the other hand, there is tiny > users are using S3/Swift(S3 in 4.0/4.1 even can’t backup snapshot, and nobody reports the issue > before, so I assume there is zero cloudstack users are using S3 in 4.0/4.1). > Then fix the upgrade path for S3 from 4.0 to 4.2 has little gain for the whole CloudStack users(as the user > base is almost zero), while fix the upgrade path from NFS to S3 will benefit the whole community a lot. > So, which one has the higher priority? Isn’t obvious? > > From: John Burwell [mailto:jburwell@...] > Sent: Friday, July 26, 2013 7:15 AM > To: dev@...<mailto:dev@...> > Cc: Min Chen > Subject: Re: [ACS42] Duplicate S3 and Swift Object Storage Features > > Edison, > > Unfortunately, given the time remaining the 4.2 release cycle, the most that can likely be done is to remove > these global options. Due to the massive amount of cruft that will be created when these global options are > removed, I am disappointed that a more a comprehensive code removal was not performed as part of this > effort. I have opened defect CLOUDSTACK-3861 to address the duplicate functionality and task > CLOUDSTACK-3862 to address removal of the dead code post 4.2.0. > > I completely disagree regarding the migration path issue. As we have discussed in the past on the list, we > have no way of knowing what features are in the use across the community. Therefore, migration paths for > feature replacements must always be provided in order to avoid a scenario where users are stranded. 4.1.0 > users employing NFS secondary storage upgrading to 4.2.0 will suffer no loss of functionality. However, > 4.1.0 users using either S3 or Swift-backed secondary storage will lose capability. I see prodded a > facility to convert NFS secondary storage to object storage as an enhancement where the lack of a > migration path is a blocking defect. As such, I have opened defect CLOUDSTACK-3360 [2] to address this issue. > > Thanks, > -John > > [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-3861 > [2]: https://issues.apache.org/jira/browse/CLOUDSTACK-3862 > [3]: https://issues.apache.org/jira/browse/CLOUDSTACK-3860 > > On Jul 25, 2013, at 6:08 PM, Edison Su > <Edison.su@...<mailto:Edison.su@...>> wrote: > > -----Original Message----- > From: John Burwell [mailto:jburwell@...<http://basho.com>] > Sent: Thursday, July 25, 2013 2:13 PM > To: dev@...<mailto:dev@...> > Cc: Min Chen > Subject: Re: [ACS42] Duplicate S3 and Swift Object Storage Features > > Edison, > > The old S3 and Swift-backed secondary storage can still be enabled (via global > options) and configured along side the new object store feature. Is there a > > Do you mean "s3.enabled" and "swift.enabled" in global configuration? This two options should be > removed, and they won't have any effect any more. > > reason why they are still present? I would have expected the code to have > been removed. > > The second question is how users utilizing those features will be migrated to > the new object storage approach. > > Haven't have time to take a look at upgrade issue yet. Should be able to upgrade from existing S3/Swift into > 4.2, but I doubt are there any users are using S3/Swift in CloudStack? > We'd better put our energy on how to upgrade existing NFS secondary storage to S3/Swift, which are the most > users of CloudStack using. > > Thanks, > -John > > On Jul 25, 2013, at 5:09 PM, Edison Su > <Edison.su@...<mailto:Edison.su@...>> wrote: > > -----Original Message----- > From: John Burwell [mailto:jburwell@...<http://basho.com>] > Sent: Thursday, July 25, 2013 2:06 PM > To: dev@...<mailto:dev@...> > Cc: Edison Su; Min Chen > Subject: [ACS42] Duplicate S3 and Swift Object Storage Features > > All, > > I have noticed during testing that the old S3 and Swift-backed > secondary > > What you mean the old s3/swift secondary? Upgrading the old s3 from 4.1 > to 4.2? > > storage features are still available in the 4.2.0. It seems to me > that they should be disabled (given the late date), and removed > completely post 4.2.0 release. Also, what is the migration/upgrade > strategy for customers using these features? > > Thanks, > -John > >
We are currently using Swift and NFS for our secondary storage. We noticed it is broken in version 4.1. Since it does not look like there will be no future support for Swift as a secondary storage, is there a way we can disable Swift and switch to just NFS? Trying to disable Swift in the global settings produces can not change swift.enable after you have added Swift cloudstack I think letting people disabling Swift will solve the problem if the plan is to phase out the support for Swift. Thanks, Vincent
