[Openstack-operators] Question regarding to referencearchitecture.org
Vivek Singh Raghuwanshi
vivekraghuwanshi at gmail.com
Tue May 1 14:19:46 UTC 2012
i agreed with Jason
On Tue, May 1, 2012 at 7:47 PM, Jason Cannavale <
jason.cannavale at rackspace.com> wrote:
> Duncan,
>
> I think it would be a great idea to get a larger set of architectures for
> easy review, let me see what I can do.
>
>
> Jason
>
> On 5/1/12 2:26 PM, "Duncan McGreggor" <duncan at dreamhost.com> wrote:
>
> >Jason,
> >
> >Folks from CERN and NeCTAR [1] have expressed interest in sharing
> >their cloud architectures and reference materials.
> >
> >Should they go through you, and get their data/images put up on
> >http://www.referencearchitecture.org/ ?
> >
> >d
> >
> >
> >[1] Associated with the University of Melbourne, http://nectar.org.au/
> >
> >On Tue, May 1, 2012 at 8:20 AM, Jason Cannavale
> ><jason.cannavale at rackspace.com> wrote:
> >> Hi Igor, Vivek,
> >>
> >> Apologies for the confusion. This site was put together quite some time
> >>ago
> >> (between Cactus and Diablo releases) and only took into consideration
> >>the
> >> nova and swift projects, and has not been updated since that time.
> >> Unfortunately, there was no consideration for nova-volumes, however your
> >> assumption is correct that the huge local storage on the compute nodes
> >>was
> >> for the image download from glance to the compute node, booting the
> >>image,
> >> and providing some local storage for the instances themselves.
> >>
> >>
> >> In the case of images and snapshots the document makes the assumption
> >>that
> >> swift was the backend for glance. In this case you would have
> >>glance-api and
> >> glance-registry running on the controller node with the swift
> >>middleware and
> >> would follow the swift portion of the reference architecture.
> >>
> >>
> >> Jason
> >>
> >> From: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>
> >> Date: Tuesday, May 1, 2012 12:59 PM
> >> To: Igor Laskovy <igor.laskovy at gmail.com>
> >> Cc: "openstack-operators at lists.openstack.org"
> >> <openstack-operators at lists.openstack.org>
> >> Subject: Re: [Openstack-operators] Question regarding to
> >> referencearchitecture.org
> >>
> >> Yes and to store images and snapshorts
> >>
> >> On Tue, May 1, 2012 at 5:11 PM, Igor Laskovy <igor.laskovy at gmail.com>
> >>wrote:
> >>>
> >>> Hi all!
> >>>
> >>> I am new to the openstack. I have question regarding to
> >>> http://www.referencearchitecture.org/physical-deployment/ .
> >>> This design shown a two controller nodes, one brand iSCSI DAS and a
> >>> lot of compute nodes. Controller nodes has small local storages and
> >>> connectivity to iSCSI DAS. Compute nodes, according to "Rule of
> >>> Thumb): 4 to 8 GB RAM and 1 Spindle Per Core", has a lot of local
> >>> spaces each one.
> >>> So how work Nova-volumes here? It is running on controller node and
> >>> use VG "nova-volumes" which based on disk via attached iSCSI DAS?
> >>> After that euca-create-volume create volume and will expose it to the
> >>> compute node via iSCSI again? If it is correct, what is the point to
> >>> use huge local storages at compute nodes, for boot image of instances
> >>> only?
> >>>
> >>> Igor Laskovy
> >>> _______________________________________________
> >>> Openstack-operators mailing list
> >>> Openstack-operators at lists.openstack.org
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> >>
> >>
> >> --
> >> ViVek Raghuwanshi
> >> Mobile -+91-09595950504
> >>
> >> Skype - vivek_raghuwanshi
> >>
> >>
> >>
> >> _______________________________________________
> >> Openstack-operators mailing list
> >> Openstack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
>
>
--
ViVek Raghuwanshi
Mobile -+91-09595950504
Skype - vivek_raghuwanshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120501/c88d9a57/attachment-0002.html>
More information about the Openstack-operators
mailing list