Hi Mike, thx for that info, that is exactly what I also see as DB differences, but was also wondering if anyone played with it in Production :)
Will wait for some more reply hopefully ! Cheers Andrija On 29 September 2017 at 15:27, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > Hi Andrija, > > I just took a look at the SolidFire logic around adding primary storage at > the zone level versus the cluster scope. > > I recommend you try this in development prior to production, but it looks > like you can make the following changes for SolidFire: > > • In cloud.storage_pool, enter the applicable value for pod_id (this > should be null when being used as zone-wide storage and an integer when > being used as cluster-scoped storage). > • In cloud.storage_pool, enter the applicable value for cluster_id (this > should be null when being used as zone-wide storage and an integer when > being used as cluster-scoped storage). > • In cloud.storage_pool, change the hypervisor_type from Any to (in your > case) KVM. > > Talk to you later! > Mike > > On 9/29/17, 5:18 AM, "Andrija Panic" <andrija.pa...@gmail.com> wrote: > > Hi all, > > I was wondering if anyone have experience hacking DB and converting > zone-wide primary storage to cluster-wide. > > We have: > 1 x NFS primary storage, zone-wide > 1 x CEPH primary storage, zone-wide > 1 x SOLIDFIRE orimary storage, zone-wide > 1 zone, 1 pod, 1 cluster., Advanced zone, and 1 NFS regular secondary > storage (SS not relevant here). > > I'm assuming few DB changes would do it - storage_pool table / scope, > cluster_id, pod_id fileds), but have not yet had time to play with it > really. > > Any advice if this is OK to be done in production environment, would be > very much appreciated. > > We plan to expand to many more racks, so we might move from > single-everything (pod/cluster) to multiple PODs/clusters etc, and thus > design Primary Storage accordingly. > > Thanks ! > > -- > > Andrija Panić > > > -- Andrija Panić
