What does ³Flavor sizes² include? Memory, CPU count? Is there a wide-enough care for other measures of performance or compatibility like: - virtualization type: none (hardware/metal), xen, kvm, hyperv - cpu speed, cache or some form of performance index - volume types: SATA, SSD, iSCSI, and a performance index
On 3/17/15, 9:22 PM, "John Dickinson" <[email protected]> wrote: > >> On Mar 17, 2015, at 1:02 PM, Davis, Amos (PaaS-Core) >><[email protected]> wrote: >> >> All, >> The Application EcoSystem Working Group realized during the mid-cycle >>meetup in Philadelphia that there is no way to get the capabilities of >>an Openstack cloud so that applications can measure their compatibility >>against that cloud. In other words, if we create an Openstack App >>Marketplace and have developers make apps to be in that marketplace, >>then we'll have no way for apps to verify that they can run on that >>cloud. We'd like to ask that there be a standard set of API calls >>created that allow a cloud to list its capabilities. The cloud >>"features" or capabilities list should return True/False API responses >>and could include but is not limited to the below examples. Also, >>https://review.openstack.org/#/c/162655/ may be a good starting point >>for this request. >> >> >> Glance: >> URL/upload >> types (raw, qcow, etc) >> >> Nova: >> Suspend/Resume VM >> Resize >> Flavor sizes supported >> Images Available >> Quota Limits >> VNC support >> >> Neutron: >> Types of Networking (neutron, neutron + ml2, nova-network aka linux >>bridge, other) >> Types of SDN in use? >> Shared tenant networks >> Anything else? >> >> >> Ceph/Cinder: >> LVM or other? >> SCSI-backed? >> Any others? >> >> Swift: >> ? > >Swift's capabilities are discoverable via an "/info" endpoint. The docs >are at: > >http://docs.openstack.org/developer/swift/api/discoverability.html > >Example output from my dev environment and from Rackspace Cloud Files and >from a SwiftStack lab cluster: > >https://gist.github.com/notmyname/438392d57c2f3d3ee327 > > >Clients use these to ensure a unified experience across clusters and that >features are supported before trying to use them. > >> >> Best Regards, >> Amos Davis >> [email protected] >> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>[email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
