[Rdo-list] Happy birthday RDO!
by Rich Bowen
(From http://community.redhat.com/blog/2014/04/happy-birthday-to-rdo/ )
A year ago today – April 15, 2013 – we announced the RDO effort. We started the project in an effort to make it less painful to deploy an OpenStack cloud on CentOS, Fedora, or Red Hat Enterprise Linux. A lot has changed over the past year, but our mission remains the same.
We’ve grown from a handful of people to more than 2,000 people registered on the forum and wiki. We’ve also got a following on Twitter and Google+, and an active group of experts fielding questions on the ask.openstack.org Q&A website.
In that time, Red Hat participation in the OpenStack project has grown, too, with Red Hat being the top contributor to the OpenStack code in the Folsom, Grizzly, Havana and (so far) Icehouse releases.
In the coming year, we’re looking forward to Juno and whatever the K release ends up being called, and the innovation around cloud computing. We’re hoping for — and working toward — big strides in ease of deployment and configuration, better metering, and all sorts of other improvements. Want to get the latest on RDO? Follow us on Twitter @RDOCommunity. Come join us as we help create the future of cloud computing.
11 years
[Rdo-list] Glance Image list not working after Keystone SSL setup
by Devendra Gupta
Hi,
I have configured keystone to SSL and also update the endpoint in
service catalog. Keystone operations like endpoint/tenant list working
fine. I also update glance-api.conf and glance-registry.conf files
with ssl enabled keystone details but still glance is unable to find
images. It fails with following:
[root@openstack-centos65 glance(keystone_admin)]# glance --insecure image-list
Request returned failure status.
Invalid OpenStack Identity credentials.
Please see attached keystone.conf, glance-api.conf and
glance-registry.conf and debug output of glance image-list and
endpoint list.
Regards,
Devendra
11 years
[Rdo-list] Trove survey for summit
by Rich Bowen
If you are interested in databases with OpenStack, or with Trove
specifically, and have a few minutes to fill out a survey to help these
folks in their research, they're giving away $100 AMEX gift cards to one
in every 100 completed surveys.
--Rich
-------- Original Message --------
Subject: [OpenStack Marketing] Can you help with this
Date: Mon, 14 Apr 2014 13:30:57 +0000
From: Lori Cohen <lori.cohen(a)tesora.com>
To: marketing(a)lists.openstack.org <marketing(a)lists.openstack.org>
Hi,
I wanted to introduce my company, Tesora. We are activity working on
the Trove project, leveraging our deep database experience to
increase the functionality of database as a service on OpenStack.
As part of this effort, we are trying to gather information on how
developers are using databases with OpenStack. We developed
a short survey that we would appreciate if you could help us to promote.
We intend to release the results at the OpenStack Summit with an
infographic and white paper.
Here is a link you can use. http://svy.mk/1ehTsqE
Thanks so much,
Lori
Lori Cohen | Marketing
Tesora <http://tesora.com/>
Direct: 617.922.7577
Check out our blog > <http://www.tesora.com/blog>
Twitter <https://twitter.com/tesoracorp> | Facebook
<https://www.facebook.com/tesoracorp> | Linkedin
<http://www.linkedin.com/company/parelastic> | Google+
<https://plus.google.com/u/0/117928183275955181789/posts>
11 years
[Rdo-list] Puppet glusterers unite
by John Eckersberg
Greetings,
For those of you in the To: line, I believe you are all doing something
with gluster and puppet at the moment. For anyone else on rdo-list that
might be interested, jump in :)
Primarily I want to get everyone talking to make sure we don't step on
each other's toes. I know James has done some great work with the
puppet-gluster module, and Gilles is currently working to switch off of
the now-deprecated puppet-openstack-storage module and onto
puppet-gluster. Crag, Jiří, and myself are working gluster-related
bugs. So let's keep in touch.
I'm working to configure libgfapi support on nova compute nodes. In the
old gluster module, there was a gluster::client class that just
installed the required glusterfs-fuse package. This class is used by
astapor in a few places (compute/cinder/glance). However there's no
gluster::client class in the new module, so we'll need to remedy that
somehow.
There is a class, gluster::mount::base, that ensures the packages are
installed, and that class is used by each instance of gluster::mount.
I'd like to reuse some of this, but I don't think we need all of it on
the compute nodes (really we just need to install glusterfs-api). The
simple way would be to create a new class glusterfs::apiclient that just
installs the package, and include that for the nova compute case.
However I'm concerned with the other places we were previously using
gluster::client. Can we use the new gluster::mount define to replace
all of these instances? Or are we going to need to refactor in those
places as well? I'd like to have some idea where this is all going
before I start ripping it apart.
Thoughts?
-John
11 years
