[Rdo-list] [OFI] Orchestration <-> Wizard Integration
by Petr Chalupa
Hello guys,
I would like to start discussion about how the integration of
Orchestration and Wizard will look like.
The parts are:
1. Collecting the configuration of OS (OpenStack) infrastructure
2. Configuring Foreman's HostGroups and other stuff based on that
configuration
3. Orchestrate the provisioning of the whole OS infrastructure in the
right order using configured HostGroups and Dynflow.
I am thinking that 1. and 2. will be part of the Wizard and 3. will be
the orchestration's job.
I am assuming that 2. is ±simple function using seed data and
user-provided configuration that creates configured HostGroups. Meaning
it does not need any of the workflow engine stuff that Dynflow provides.
If so then developing these in parallel and connecting them later should
be quite easy. I and Martyn can simulate the OS infrastructure
provisioning with blank hosts for now.
Petr
10 years, 9 months
[Rdo-list] Testing tool for upcoming test day
by Rich Bowen
With assistance from Kashyap and the fine folks on #fedora-admin, we'll
be using the Fedora Test Day tools for the upcoming test day. I'm in the
process of populating it with the existing test cases, and wanted to let
you all know about it so that you can create necessary accounts, poke
around on it, and help me get the necessary test cases in there. This
will also make it a lot easier to set things up for the next run-through
on this.
The test day app is at
http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16
This is where you will see what tests need to be done, read the
instructions for each, and enter your results from each as you go along.
It's also where we'll see everyone's results at the end of the day.
The Fedora Test Day page for this test day is at
http://fedoraproject.org/wiki/Test_Day:2014-03-19_RDO This is for folks
that participate in the Fedora testing world, who might stumble across
our event and do some testing of their own. Hey, it could happen.
And https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata is
the metadata page that lists the test cases. This is where you can
edit/add/remove test cases if you want to help me with that, or if you
have things that you'd like to see tested. The format of this page
matters, since it's parsed by the test day app, so please follow the
examples when you make changes.
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/
10 years, 9 months
[Rdo-list] Question about Neutron Security Groups
by Daniel Speichert
Hello,
I have a problem with Neutron security groups and I hoped you could
provide some ideas.
I have two different cloud installation based on OpenStack Havana, they
both use Neutron setup with multiple tenants and routers.
First cloud is based on Ubuntu and has both Neutron and Nova security
groups enabled (a mistake in configuraiton, I did not add
"firewall_driver=nova.virt.firewall.NoopFirewallDriver" to nova.conf. On
its compute nodes it has neutron-openvswitch-* iptables chains and
nova-instance* chains.
Rules from all of these chains seem to get hits and security groups work
properly. This cloud uses GRE tunnels.
Second cloud is based on CentOS 6.5 with RDO. It has the same Neutron
setup and nova security groups disabled and
"security_group_api=neutron". It does not have iptables chains
nova-instance* but neutron chains are properly applied. None of these
chains get any hits at all and all traffic to instances is allowed. This
cloud used VXLANs but I switched to GRE which did not help.
On both clouds there are no additional iptables rules besides the ones
generated by OpenStack - I flushed all the rules and chains and forced
sync by adding a security group rule.
Do you have any idea why security groups don't work, i.e. the chains
don't get traffic? It seems to me that the rules in chains
neutron-openvswi-FORWARD and neutron-openvswi-INPUT don't get any hits
at all on my second cloud installation.
--
Best Regards,
Daniel
10 years, 9 months
Re: [Rdo-list] [rhos-dev] [OFI] Wireframes and UI related question
by Hugh O. Brock
On Wed, Mar 05, 2014 at 09:50:31AM -0500, Liz Blanchard wrote:
>
> On Mar 5, 2014, at 5:47 AM, Marek Hulan <mhulan(a)redhat.com> wrote:
>
> > On Wednesday 05 of March 2014 10:59:53 Marek Hulan wrote:
> >> Hello,
>
> Hi Marek,
>
> Great questions. I will do my best to answer them.
Thanks for jumping in Liz -- more below. Taking this to rdo-list and foreman-dev...
> >> I have a few questions regarding latest wireframes I found here [1]. I think
> >> page 6 describes assignment of various services to hostgroups which would
> >> allow user to define custom layout. Is that page intended for post-April
> >> work? Is the selection of Deployment layout on page 5 only layout
> >> configuration we'll support for April drop?
>
> Right. We decided to only allow the user to select to add optional services to host groups for this first release. This is the only thing that they can customize with respect to host groups for April.
>
> Hugh - Would you confirm this? Should we instead just tell the user which services will be included for each host group (including optional ones)?
In fact, I would suggest we allow *no* customization of the
services-per-hostgroups for April, unless it turns out to be INCREDIBLY
EASY. We are targeting two tightly defined reference architectures
(distributed 3-node, and distributed-plus-HA 5+-node) for which the
services will be predefined. I think we need to limit the April offering
to that and plan to add limited service-per-node configuration for
June.
> >>
> >> Looking at page 7 and 8, do we want to display all possible configuration
> >> options (class parameters) of a given service (puppet module) to user? Or
> >> should we display just most important (probably the case) and leave rest
> >> hidden or even under some "advanced" link?
>
> The goal of the wizard is just to display the important parameters to the user. This way they can quickly get through the wizard and have an OpenStack environment up and running. Later, they could go into the settings and update any parameter that they need to. We may need to pull in more settings than those shown in the wireframes if we identify others that are crucial for first time set-up. Also, the goal is to have smart defaults for all of these parameters so that the user would be able to just click through if they don’t want to change anything and the deployment would kick off.
Yeah, absolutely right Liz. It's an important UX exercise to get the
right set of parameters in the UI, and a further coding exercise to set
the rest via hidden defaults. We *don't* want to allow configuration of
every conceivable value right now.
> >>
> >> Last but not least, if we have parameters which values are limited by some
> >> fixed set (e.g. hypervisor can be KVM, QEMU, VCENTER or Driver Backend) do
> >> we need to use both - radio buttons and select box instead of one field
> >> type? Is there some rule (e.g. number of possible values) for this? I'm
> >> asking because I think we should generate forms based on parameter
> >> attributes we have in DB so I'd like to know what attributes are we missing
> >> at the moment.
>
> Great question. Typically radio buttons would be used for two values and then a drop-down would be used for 3+. I think in the example you point out (KVM, QEMU, VCENTER) this is a tricky one because if the user hasn’t selected to use Neutron networking, they won’t see the VCENTER option. So technically the wireframes should show a drop down in this case, but if there were only two options here, I’d expect a radio button. Thoughts on this?
For the moment I want to stay away from form generation, for the reasons
I described above (and in general because we have great UX designers,
who are much more capable than autogenerated forms :D). Over time, I do
think it could be useful to have metadata that describes the parameters
we want to collect and the type of widget that should be used to collect
them (the decision on that should be UX-driven, not automated), and that
metadata could be used to generate the form. But let's not attempt that
for April.
> >>
> >> [1]
> >> http://file.bos.redhat.com/~lsurette/RHOS/2014-03-03_ofi-ui_wireframes.pdf
> >
> > Adding [OFI] tag that I missed in subject so people using filters will see
> > this.
> >
Thanks for raising these questions, it's very timely.
Take care,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Senior Engineering Manager, Cloud Engineering ==
== Tuskar: Elastic Scaling for OpenStack ==
== http://github.com/tuskar ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
10 years, 9 months
[Rdo-list] [Neutron] Fwd: Icehouse with Neutron and ML2 on RHEL
by Steve Gordon
Hi all,
I got some feedback about some issues with Icehouse RDO packages, specifically the Neutron ones and the way they handle (or don't handle) the database. Are these issues we are aware of/tracking? Matt is using the EL6 builds at the moment. We are hanging out in #openstack-docs on Freenode if you need any more info from Matt (Sam-I-Am on IRC).
Thanks,
Steve
----- Forwarded Message -----
> FYI...
>
> ---------- Forwarded message ----------
> From: Phil Hopkins <phil.hopkins(a)rackspace.com>
> Date: Sat, Mar 1, 2014 at 8:13 PM
> Subject: Re: Icehouse with Neutron and ML2 on RHEL
> To: Matt Kassawara <mkassawara(a)gmail.com>
> Cc: Carl Perry <edolnx(a)gmail.com>, Edgar Magana <emagana(a)plumgrid.com>,
> Nick Chase <nchase(a)mirantis.com>
>
>
> Very interesting, something is broke bad there. There should be a new
> build of the packages this week. Lets hope that fixes this.problem.
>
> Phil
>
> Sent from my iPhone
>
> On Mar 1, 2014, at 8:29 PM, "Matt Kassawara" <mkassawara(a)gmail.com> wrote:
>
> The following tables appear after starting neutron-server with a fresh
> database:
>
> mysql> show tables;
> +---------------------+
> | Tables_in_neutron |
> +---------------------+
> | agents |
> | ml2_gre_allocations |
> | ml2_gre_endpoints |
> | networks |
> | quotas |
> | securitygroups |
> +---------------------+
> 6 rows in set (0.00 sec)
>
> The log shows plenty of errors regarding missing database information. I'm
> particularly curious about this one:
>
> 2014-03-01 18:58:55.133 2877 INFO neutron.db.api [-] Database registration
> exception: (OperationalError) (1005, "Can't create table
> 'neutron.networkdhcpagentbindings' (errno: 150)") '\nCREATE TABLE
> networkdhcpagentbindings (\n\tnetwork_id VARCHAR(36) NOT NULL,
> \n\tdhcp_agent_id VARCHAR(36) NOT NULL, \n\tPRIMARY KEY (network_id,
> dhcp_agent_id), \n\tFOREIGN KEY(network_id) REFERENCES networks (id) ON
> DELETE CASCADE, \n\tFOREIGN KEY(dhcp_agent_id) REFERENCES agents (id) ON
> DELETE CASCADE\n)ENGINE=InnoDB\n\n' ()
>
> Interestingly, trying this SQL command manually also fails:
>
> mysql> create table networkdhcpagentbindings (network_id varchar(36) not
> null, dhcp_agent_id varchar(36) not null, primary key (network_id,
> dhcp_agent_id), foreign key(network_id) references networks (id) on delete
> cascade, foreign key(dhcp_agent_id) references agents (id) on delete
> cascade ) engine=InnoDB;
> ERROR 1005 (HY000): Can't create table 'neutron.networkdhcpagentbindings'
> (errno: 150)
>
> However, it works without "engine=InnoDB" appended at the end which leads
> me to some sort of referential integrity problem... or I'm mistyping
> something. :)
>
> mysql> show engine innodb status;
> LATEST FOREIGN KEY ERROR
> ------------------------
> 140301 19:24:40 Error in foreign key constraint of table
> neutron/networkdhcpagentbindings:
> foreign key(dhcp_agent_id) references agents (id) on delete cascade)
> engine=InnoDB:
> Cannot resolve table name close to:
> (id) on delete cascade) engine=InnoDB
>
> In comparison, here's the neutron database tables from my functional
> Ubuntu installation:
>
> mysql> show tables;
> +---------------------------+
> | Tables_in_neutron |
> +---------------------------+
> | agents |
> | allowedaddresspairs |
> | dnsnameservers |
> | externalnetworks |
> | extradhcpopts |
> | floatingips |
> | ipallocationpools |
> | ipallocations |
> | ipavailabilityranges |
> | ml2_gre_allocations |
> | ml2_gre_endpoints |
> | ml2_network_segments |
> | ml2_port_bindings |
> | networkdhcpagentbindings |
> | networks |
> | ports |
> | quotas |
> | routerl3agentbindings |
> | routerroutes |
> | routers |
> | securitygroupportbindings |
> | securitygrouprules |
> | securitygroups |
> | subnetroutes |
> | subnets |
> +---------------------------+
> 25 rows in set (0.00 sec)
>
>
>
> On Sat, Mar 1, 2014 at 6:46 PM, Phil Hopkins
> <phil.hopkins(a)rackspace.com>wrote:
>
> > I was thinking nova not neutron. Try dropping the neutron database,
> > recreate it and restart the neutron-server service.
> >
> > That should rebuild the tables. Check and see if they are created. If so
> > then see if the error reoccurs.
> >
> > Also see if any errors show up when the neutron-server service is
> > restarted. Maybe it is having trouble creating the database tables.
> >
> > Phil
> >
> > Sent from my iPhone
> >
> > On Mar 1, 2014, at 7:00 PM, "Matt Kassawara" <mkassawara(a)gmail.com> wrote:
> >
> > I did that a few times. Unlike the other similar utilities,
> > neutron-db-manage doesn't offer a "sync" command.
> >
> >
> > On Sat, Mar 1, 2014 at 5:52 PM, Phil Hopkins
> > <phil.hopkins(a)rackspace.com>wrote:
> >
> >> You might try rerunning the db sync to ensure the database tables are
> >> built correctly.
> >>
> >> Phil
> >>
> >> Sent from my iPhone
> >>
> >> On Mar 1, 2014, at 6:21 PM, "Matt Kassawara" <mkassawara(a)gmail.com>
> >> wrote:
> >>
> >> Fresh.
> >>
> >>
> >> On Sat, Mar 1, 2014 at 5:19 PM, Phil Hopkins
> >> <phil.hopkins(a)rackspace.com>wrote:
> >>
> >>> Was this a fresh install or an upgrade?
> >>>
> >>> Phil
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Mar 1, 2014, at 5:04 PM, "Matt Kassawara" <mkassawara(a)gmail.com>
> >>> wrote:
> >>>
> >>> If you thought getting Icehouse with Neutron/ML2 working on Ubuntu
> >>> took some effort, the RHEL situation appears much worse. All of the
> >>> Neutron
> >>> daemons spew database errors about missing tables and/or inability to
> >>> create them.
> >>>
> >>> For example:
> >>>
> >>> [root@hst-osctl8 neutron]# neutron net-list
> >>> Request Failed: internal server error while processing your request.
> >>>
> >>> From the server log...
> >>>
> >>> 2014-03-01 15:37:07.970 2584 INFO urllib3.connectionpool [-] Starting
> >>> new HTTP connection (1): hst-osctl8
> >>> 2014-03-01 15:37:08.133 2584 ERROR neutron.api.v2.resource
> >>> [req-9ec4eec0-bf1b-4720-af03-fbdba6a03c14 None] index failed
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource Traceback
> >>> (most recent call last):
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/resource.py", line 84,
> >>> in
> >>> resource
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource result =
> >>> method(request=request, **args)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/base.py", line 279, in
> >>> index
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource return
> >>> self._items(request, True, parent_id)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/base.py", line 233, in
> >>> _items
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource obj_list
> >>> = obj_getter(request.context, **kwargs)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/plugins/ml2/plugin.py", line
> >>> 367,
> >>> in get_networks
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource limit,
> >>> marker, page_reverse)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/db/db_base_plugin_v2.py", line
> >>> 1029, in get_networks
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>> page_reverse=page_reverse)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib/python2.6/site-packages/neutron/db/db_base_plugin_v2.py", line
> >>> 196, in _get_collection
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource items =
> >>> [dict_func(c, fields) for c in query]
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py",
> >>> line 2227, in __iter__
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource return
> >>> self._execute_and_instances(context)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py",
> >>> line 2242, in _execute_and_instances
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource result =
> >>> conn.execute(querycontext.statement, self._params)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
> >>> line 1449, in execute
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource params)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
> >>> line 1584, in _execute_clauseelement
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>> compiled_sql, distilled_params
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
> >>> line 1698, in _execute_context
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource context)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
> >>> line 1691, in _execute_context
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource context)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py",
> >>> line 331, in do_execute
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>> cursor.execute(statement, parameters)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 173, in
> >>> execute
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>> self.errorhandler(self, exc, value)
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File
> >>> "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 36, in
> >>> defaulterrorhandler
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource raise
> >>> errorclass, errorvalue
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>> ProgrammingError: (ProgrammingError) (1146, "Table
> >>> 'neutron.externalnetworks' doesn't exist") 'SELECT networks.tenant_id AS
> >>> networks_tenant_id, networks.id AS networks_id, networks.name AS
> >>> networks_name, networks.status AS networks_status,
> >>> networks.admin_state_up
> >>> AS networks_admin_state_up, networks.shared AS networks_shared,
> >>> externalnetworks_1.network_id AS externalnetworks_1_network_id \nFROM
> >>> networks LEFT OUTER JOIN externalnetworks ON networks.id =
> >>> externalnetworks.network_id LEFT OUTER JOIN externalnetworks AS
> >>> externalnetworks_1 ON networks.id = externalnetworks_1.network_id' ()
> >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource
> >>>
> >>> Although I haven't needed to use it before, I poked around at various
> >>> permutations of neutron-db-manage, all of which failed with various SQL
> >>> errors. I also dissected the functional neutron-server package on Ubuntu
> >>> and found no post-installation script calls to neutron-db-manage. On a
> >>> related note, Steve Gordon told me that RH should release icehouse-3
> >>> packages this week which might address this issue.
> >>>
> >>>
> >>
> >
>
--
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)
10 years, 9 months
[Rdo-list] [Rdo-newsletter] RDO Newsletter: March 2014
by Rich Bowen
Hi again, and thanks for being part of the RDO community. We've got a
number of events coming up, and various ways you can get involved in
the RDO project, as well as the upstream OpenStack community, but
first, a little bit about what's happened since the last time I wrote.
February events
Last week, Lars Kellogg-Stedman hosted a Google Hangout in which he
talked about standing up a multi-node OpenStack installation using
RDO and Packstack. You can watch that presentation at
https://plus.google.com/events/cm9ff549vmsim737lj7hopk4gao and the
slides from the presentation, including cut-and-paste command lines
to reproduce the setup yourself, can be found at http://goo.gl/Yvmd0P
Other past RDO hangouts can be seen at
http://openstack.redhat.com/Hangouts along with announcements of
upcoming ones.
When last I wrote, I was in Belgium attending FOSDEM. That event was
fantastic, and a little overwhelming, with over 5000
Free/Libre/OpenSource Software enthusiasts descending on the
University of Brussels to celebrate and learn about various software
projects and the issues surrounding them. While there, I interviewed
Ohad Levy, who works on deploying OpenStack with The Foreman, about
his work. Unfortunately, I managed to turn off the recorder before we
started talking, and I have nothing to show for it. We'll be having
that conversation again over the phone in the coming days, and I'll
publish that on the RDO website.
Additionally, I attended Configuration Management Camp -
http://cfgmgmtcamp.eu/ - and Infrastructure.next -
http://lanyrd.com/2014/infranext/ - in Ghent, which focused on issues
that are important to us in the OpenStack world - configuration
management, automation, and monitoring.
Last weekend, RDO had a table at SCaLE - the Southern California
Linux Expo - http://www.socallinuxexpo.org/blog/scale-12x - where we
had steady traffic through the whole event, with people telling us
how much they love RDO, and other folks asking a lot of great
questions about OpenStack, and where it fits into the larger cloud
ecosystem, including projects like oVirt and OpenShift, who were our
neighbors in our booth.
Upcoming events
We are planning our next RDO Test Days on March 19th and 20th. We'll
be testing the third Icehouse milestone in preparation for the final
release of Icehouse on April 17th. You can find more about the test
day, and sign up to participate, at
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3
We'll be hosting another Google Hangout on Thursday, March 27th.
Flavio Percoco will be telling us about the Marconi project -
https://wiki.openstack.org/wiki/Marconi - what it is, what the plans
are for the coming releases, and how you can get involved in the
development of this new piece of OpenStack infrastructure. That event
will be streamed live (and available recorded afterwards) at
https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk
and you can add it to your calendar there to get a reminder
closer to the event.
Finally, don't forget that the OpenStack Summit is just around the
corner - May 12-16th in Atlanta, Georgia, USA. The vote has just
closed for what sessions will be presented there - many thanks to
those of you who voted - and now the selection process starts, with
track chairs putting together the schedule from the sessions that did
well in that process. We should see the schedule published in the
coming month, and then it's off to Atlanta. We hope to see you there.
Red Hat will have a booth there, featuring demos of RDO as well as
our commercial OpenStack offering. We'd love to see you there - get
your tickets early to take advantage of the early bird rates.
Stats
It's always fun to look at the statistics around OpenStack. They
shift so quickly, even from hour to hour, and it's exciting to watch
the progress of the project by the numbers.
One great place to find statistics is the Stackalytics site -
http://www.stackalytics.com/ - where you can watch contributions by
company, by module, by release, or by individual contributor.
Something I find particularly interesting, as a writer, is that the
second most active module within the ecosystem is the
openstack-manuals project. 7% of contributions are to the
documentation, second only to nova.
For RDO-specific statistics, we have
http://openstack.redhat.com/stats/ which was put together by
Bitergia, the same company that does the Stackalytics site. Here you
can track who's involved in the wiki, the mailing lists, and the
development of the code.
Get Involved
As always, a few reminders of how you can get involved in the RDO
project.
The wiki, at http://openstack.redhat.com/Docs , is one of the best
ways you can share your experience with the rest of the RDO
community. Articles about getting various scenarios working,
corrections or addenda to existing articles, or suggestions for
articles that you'd like to see written, are all a great help to
people trying to run OpenStack.
If you have questions, or if you want to help answer other people's
questions, go to http://ask.openstack.org/ where there are questions
from all over the OpenStack community - not just RDO users - and
answers from experts on a variety of aspects of OpenStack. This is
the best place to ask your questions, or to find other people who
have already asked your question and received answers and advice.
If mailing lists are more to your liking, the rdo-list mailing list
is the place to ask your questions and help other folks out with
theirs. You can sign up for the list, or make alterations to your
subscription, at http://www.redhat.com/mailman/listinfo/rdo-list
And finally, you can adjust your subscription to this newsletter, or
invite your colleagues, at
http://www.redhat.com/mailman/listinfo/rdo-newsletter
Thanks again for being part of the RDO community. We look forward to
seeing your contributions.
--
Rich Bowen, for the RDO community
rbowen(a)redhat.com
http://openstack.redhat.com/
@rdocommunity
_______________________________________________
Rdo-newsletter mailing list
Rdo-newsletter(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-newsletter
10 years, 9 months
