fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

On Wed, Dec 18, 2013 at 8:27 AM, Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx
> wrote:

> On Dec 18, 2013 7:09 AM, "Mike Scherbakov" <mscherbakov@xxxxxxxxxxxx>
> wrote:
> > Do I miss anything in the above?
>
> No.
>
> > Do we plan to have it documented anywhere so it is easy to understand
> for the user, who might be not very well experienced with all cinder, lvm,
> ephemeral, ceph, swift, rbd and other terms?
>
> It is documented to some extent in settings descriptions and a bit more in
> the Reference Architecture. Maybe it's worth adding more details to the
> Storage Architecture section? Should there be a link to that section
> somewhere in the UI?
>
I updated the UI descriptions to be less confusing
https://review.openstack.org/#/c/62501/

> > What does mean checkbox "Cinder LVM over iSCSI for volumes" - what are
> the use cases for it?
>
> It is the default Cinder option from your list. The primary use case is
> where the cloud administrator doesn't need additional redundancy provided
> by Ceph and needs to maximize data density for volumes.
>
> > Do we need cinder role applied to any servers if we use Ceph everywhere?
>
> No.
>
The new description for cinder should help understand this.

> > Will RadosGW conflict with Swift in HA mode?
>
> Yes. This is reflected in the RadosGW setting description.
>
Swift must be set as the keystone endpoint for the service 'swift', this
prevents RadosGW from working with swift, it also prevents installing swift
to work as the glance backend as it requires the same endopoint.

> > Did we create bugs about unneeded LVMs for Glance, /var/lib/nova if we
> use Ceph? Or we still need LVMs?
>
> Our discussionon this yesterday was a bit inconclusive. I'm in favor of
> keeping the LVMs in 4.0 do as not to destabilize the release, and removing
> them in 4.1. If there are no objections I will create bugs targeted for 4.1.
>
> > Are there any other combinations which may lead to side effects? Can we
> have all of them verified?
>
> No, I don't think so.
>
Without multiple backends support adding the cinder role to a controller
would cause one of them to win depending on who went last resulting in the
other being left out of the cinder config.

> > How many of the things above are covered by system tests, and how many
> still need to be covered?
>
The problem above is likely not covered, i think the rest are.

> > Do we have multiple backend support in Cinder?
>
> No. Andrew started this work but it was held back by the splinters bug.
>
The patch was applied to upstream puppet-cinder and can be included into
fuel without issue but i haven't had time to weave it into our manifests.

> > The whole UX with only checkboxes doesn't look like ideal solution to
> me. What do you think folks, should we file a blueprint and implement
> better UX for it in future versions?
>
> TBH I would have a single checkbox in the wizard that would enable all
> Ceph options. Not sure what we can do about the checkboxes in the settings
> tab though.
>
The current solution is a the result of not being able to change the
settings context based on the deployment topology (multi-node vs HA). We
went through a couple of variations before settling on the current method.
The problem lies from the fact that swift isn't installed in multi-node so
object and glance wording changes between the two.


On Wed, Dec 18, 2013 at 8:27 AM, Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx
> wrote:

> On Dec 18, 2013 7:09 AM, "Mike Scherbakov" <mscherbakov@xxxxxxxxxxxx>
> wrote:
> > Do I miss anything in the above?
>
> No.
>
> > Do we plan to have it documented anywhere so it is easy to understand
> for the user, who might be not very well experienced with all cinder, lvm,
> ephemeral, ceph, swift, rbd and other terms?
>
> It is documented to some extent in settings descriptions and a bit more in
> the Reference Architecture. Maybe it's worth adding more details to the
> Storage Architecture section? Should there be a link to that section
> somewhere in the UI?
>
> > What does mean checkbox "Cinder LVM over iSCSI for volumes" - what are
> the use cases for it?
>
> It is the default Cinder option from your list. The primary use case is
> where the cloud administrator doesn't need additional redundancy provided
> by Ceph and needs to maximize data density for volumes.
>
> > Do we need cinder role applied to any servers if we use Ceph everywhere?
>
> No.
>
> > Will RadosGW conflict with Swift in HA mode?
>
> Yes. This is reflected in the RadosGW setting description.
>
> > Did we create bugs about unneeded LVMs for Glance, /var/lib/nova if we
> use Ceph? Or we still need LVMs?
>
> Our discussionon this yesterday was a bit inconclusive. I'm in favor of
> keeping the LVMs in 4.0 do as not to destabilize the release, and removing
> them in 4.1. If there are no objections I will create bugs targeted for 4.1.
>
> > Are there any other combinations which may lead to side effects? Can we
> have all of them verified?
>
> No, I don't think so.
>
> > How many of the things above are covered by system tests, and how many
> still need to be covered?
> > Do we have multiple backend support in Cinder?
>
> No. Andrew started this work but it was held back by the splinters bug.
>
> > The whole UX with only checkboxes doesn't look like ideal solution to
> me. What do you think folks, should we file a blueprint and implement
> better UX for it in future versions?
>
> TBH I would have a single checkbox in the wizard that would enable all
> Ceph options. Not sure what we can do about the checkboxes in the settings
> tab though.
>
> -Dmitry
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
If google has done it, Google did it right!