[Rdo-list] [Rdo-newsletter] RDO Newsletter, April 2014
by Rich Bowen
Happy Birthday RDO!
Happy Birthday RDO! It's been a year since we launched the RDO
project, in an attempt to make installing OpenStack on CentOS,
Fedora, and Red Hat Enterprise Linux a more pleasant experience. In
that year we've grown from nothing to over 2000 downloads a day, and
our community has grown to thousands across mailing lists, IRC
channel, Twitter, Google+, and ask.openstack.org. You can see some of
the statistics around the RDO effort at
http://openstack.redhat.com/stats/ compiled by our friends at
Bitergia.
Thank you all for your participation in this effort, and for your
hard work in making it happen! Thanks for being part of the RDO
community!
Please Take the OpenStack Community Survey
Once again, the OpenStack Foundation is conducting a survey of
OpenStack users. Please take ten minutes to fill out the survey, so
that we can get a clearer picture of who is using OpenStack, what
they're using it for, and how they'll be using it in the coming year.
Start the survey at https://www.openstack.org/user-survey/Login
Hangouts
Last week, Flavio Percoco gave us a great introduction to OpenStack
Marconi. Marconi is a project to develop a messaging and notification
service, which is undergoing OpenStack incubation. If you missed it,
you can watch at https://www.youtube.com/watch?v=qe7qI3WY97c If you
have followup questions, you can take them to the #openstack-marconi
IRC channel on the Freenode network.
You can see other past hangouts at
http://openstack.redhat.com/Hangouts
In April we'll be doing another hangout. This time the Heat team will
be telling us about how you can use Heat to orchestrate your cloud.
Watch http://openstack.redhat.com/Events for more details as they
become available.
April and May events
April and May are exciting months for OpenStack, as we anticipate the
OpenStack Icehouse release on April 17th, and the OpenStack Juno
Summit starting May 12 in Atlanta -
https://www.openstack.org/summit/openstack-summit-atlanta-2014/
But that's not all that's going on.
In the RDO community we've been following the CentOS Cloud SIG effort
closely. We see a lot of people deploying production OpenStack clouds
with RDO on CentOS and Scientific Linux, and so we are excited to see
the CentOS developer community working towards a strong Cloud
ecosystem. CentOS will be holding a dojo (community event) at the
CloudStack Collaboration Conference (CCC) in Denver, Colorado, on
April 10th. This event will include discussion of cloud deployments
on CentOS. If you're attending either CCC or ApacheCon
(http://na.apachecon.com/ ) consider staying for the CentOS dojo. See
the schedule of events at
http://cloudstackcollabconference2014.sched.org/overview/type/centos+dojo...
and register at
https://www.regonline.com/Register/Checkin.aspx?EventID=1499698
The following week, April 14-17, the Red Hat Summit will be held in
San Francisco. In addition to content about Red Hat Enterprise Linux
and other Red Hat products, there will be a substantial number of
OpenStack and RDO talks, which we've listed in the blog post at
http://openstack.redhat.com/forum/discussion/970/red-hat-summit-april
-14th-17th-san-francisco
OpenStack is currently in Feature Freeze. Thierry has a great
explanation at
http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/ of
why we do this. And on April 17th, we expect OpenStack Icehouse to be
released.
Then, two weeks later, we'll be in Atlanta for the OpenStack Summit.
It's the best place to learn about OpenStack, from installation to
monitoring, from community to code. And RDO will be there. We'll have
a booth where we'll be doing demos of various aspects of OpenStack
using RDO, and we'll have engineers there presenting a wide range of
presentations and hands-on labs - you can find those listed at
http://community.redhat.com/events/#openstacksummitus If you're at
Summit, please drop by the RDO booth to tell us your OpenStack
stories.
For those of you on the opposite side of the planet, LinuxCon Tokyo
will be held May 20-22, and RDO will have a booth presence there,
too, with several people from the RDO community in attendance. You
can see more information about that event at
http://events.linuxfoundation.org/events/linuxcon-japan although as
of this writing the schedule has not yet been published.
Stay in touch
There's lots of ways to stay in touch with what's going on at RDO.
For question-and-answer, we rely on http://ask.openstack.org/ Just be
sure to tag your question as #rdo if you want the attention of the
RDO engineers. ask.openstack.org gives you access to the best minds
in the OpenStack community, as well as an archive of previous
questions and answers that you can search.
If you're more of a mailing list fan, the rdo-list mailing list is
the place to be. It's fairly low volume - 3-5 messages a day - and a
great place to get personal attention to your questions.
And if you just want to get periodic updates on what's going on,
we're on Twitter at @RDOCommunity. And don't forget to look at
http://openstack.redhat.com/Events to see where RDO people will be
speaking around the world.
--
Rich Bowen, for the RDO Community
Follow us on Twitter at @RDOCommunity
Manage your newsletter subscription at
http://www.redhat.com/mailman/listinfo/rdo-newsletter
See also the rdo-list mailing list at
http://www.redhat.com/mailman/listinfo/rdo-list
_______________________________________________
Rdo-newsletter mailing list
Rdo-newsletter(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-newsletter
10 years
[Rdo-list] [OFI] Speeding up OFI provisioning in Dev env
by Martyn Taylor
If you are like me and you have a dog slow connection and you are
wanting to test orchestration on using Staypuft, it can take forever and
a day. The main issue for me was that the network installs were taking
hours, if you are using Fedora etc... you can quite easily use a proxy
like Squid to cache everything. However, I am using RHEL which is
usually behind SSL. It's not impossible to get round this with squid,
but you'll need to play around with man in the middle stuff.
One quick and easy way to speed up network install for RHEL and any
other distro, is just to download the DVD iso, mount it, then service it
up via apache. You'll still need to do some public traffic as you'lll
need to download all the OpenStack modules etc... but this has taken
provision time of a host for me from about 90 mins to about 15mins.
Since we are provisioning sequentially that makes a massive difference.
Here are the steps involved:
*1. Add a entry in /etc/hosts for your virtual host:*
192.168.100.1 mirrors.local
*2. create a new virtual host file, /etc/httpd/conf.d/06-local-mirrors.conf*
<VirtualHost mirrors.local:80>
ServerName mirrors.local
DocumentRoot /var/www/html/repos
</VirtualHost>
<Directory "/var/www/html/repos">
Options +Indexes
</Directory>
*3. Download the your ISO of choice and mount it somewhere:*
mkdir /mnt/rhel-iso
mount -o loop <ISO> /mnt/rhel-iso
*
**4. Create symlink to the ISO*
mkdir /var/www/html/repos
ln -s /mnt/rhel-iso /var/www/html/repos
*5. Add your new install media in foreman as normal, adding the URL to
your ISO*
path: http://mirrors.local/rhel
10 years
[Rdo-list] RDO and MariaDB+Galera
by Ryan O'Hara
I've been working on getting mariadb+galera working with RDO, and we
now have packages build in COPR. You can get F20 packages here [1].
RHEL6 packages will be rebuilt as soon as I fix a couple issues in the
spec file.
I've also submitted two new package reviews for inclusion in
Fedora [2,3]. The packaging here is a bit tricky because of the
conflicts with mariadb. As the packages exist today, most of the
mariadb-galera subpackages will conflict with the mariadb
subpackages. If you're so inclined, please take time to review the
packages.
As packages make there way into our repos, packstack will soon deploy
mariabdb-galera-server by default. For now, it will not deploy a
galera cluster, so there should be no impact. For those that want to
deploy a galera cluster, the process would simply be a matter of
installing mariabdb-galera-server on additional machines and adding
appropriate cluster configuration.
Ryan
[1] http://copr.fedoraproject.org/coprs/rohara/mariadb-galera-fedora-20/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1083232
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1083234
10 years
Re: [Rdo-list] PackStack with multiple Compute Node.
by Assaf Muller
----- Original Message -----
> Thank you for the reply.
>
I forgot to ask you, what are you using for your tenant networks?
VLANs, flat, GRE or VXLAN?
> But I'd wanna know something more detail; I mean, how could the network be
> constructed?
>
> Even if we use two different physical networks, the configuration seems not
> easy to deploy.
>
> which files should be modified or configured at allinone PackStack?
>
You'd only have to change the Packstack answer file. You should run
packstack --gen-answer-file=ans
'ans' will contain an answer file with all-in-one default values.
You should add all of the compute nodes to the compute node list
(Providing their management IP). If you're using VLANs then fill
in the bridge mappings keys (You'll put in the second NIC there),
or if you're using tunnels then specify the 2nd NIC as the tunnel
endpoint. The RDO docs have more specifics.
> Anyway, I really appreciate your kind.
>
> Best regards,
>
> Byeong-Gi Kim
>
>
> 2014-04-02 19:37 GMT+09:00 Assaf Muller <amuller(a)redhat.com>:
>
> > ----- Original Message -----
> > > Hello.
> > >
> >
> > Hi!
> >
> > > I installed Packstack for Openstack allinone installation, and I'm now
> > trying
> > > to add several compute nodes using different PCs.
> > >
> > > According to http://openstack.redhat.com/Adding_a_compute_node , the
> > > additional Compute Nodes seems to connect with the PC what allinone has
> > been
> > > installed by PackStack via a LAN; Data Network and Management Network
> > > described in the OpenStack Havana 3 node (Network Node, Compute Node, and
> > > Controller Node) setup guide look like sharing the LAN cable.
> > >
> > > Conceptually, two networks need to use different port. Do the additional
> > > Compute Nodes use a LAN as a trunk port to distinguish between the
> > networks?
> > > Or could you explain how does the multiple connection in PackStack work?
> > >
> >
> > The easiest configuration (from Packstack's point of view) would be to use
> > two
> > different physical networks, with one NIC connected to each. So, for
> > example,
> > you could have eth0 of all nodes connected to the management network, and
> > eth1
> > connected to the VM / data network.
> >
> > Otherwise, you'd use two VLAN devices over your single NIC
> > (You'd have to configure this, Packstack doesn't do this for you).
> > Then place eth0.100, eth0.200 in your answer file where appropriate.
> >
> > If you get any failures, you could post your answer file and I'll take a
> > look.
> >
> > > Thanks in advance!
> > >
> > > Byeong-Gi Kim
> > >
> > > _______________________________________________
> > > Rdo-list mailing list
> > > Rdo-list(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/rdo-list
> > >
> >
>
10 years
[Rdo-list] PackStack with multiple Compute Node.
by BYEONG-GI KIM
Hello.
I installed Packstack for Openstack allinone installation, and I'm now
trying to add several compute nodes using different PCs.
According to http://openstack.redhat.com/Adding_a_compute_node, the
additional Compute Nodes seems to connect with the PC what allinone has
been installed by PackStack via a LAN; Data Network and Management Network
described in the OpenStack Havana 3 node (Network Node, Compute Node, and
Controller Node) setup guide look like sharing the LAN cable.
Conceptually, two networks need to use different port. Do the additional
Compute Nodes use a LAN as a trunk port to distinguish between the
networks? Or could you explain how does the multiple connection in
PackStack work?
Thanks in advance!
Byeong-Gi Kim
10 years
Re: [Rdo-list] Firewall issue/error when spawning instances on compute node
by Andrew Lau
I opened a BZ here https://bugzilla.redhat.com/show_bug.cgi?id=1082188
Did you also run into this issue too,
https://bugzilla.redhat.com/show_bug.cgi?id=1082187
On Sat, Mar 29, 2014 at 2:00 AM, St. George, Allan L. <
ALLAN.L.ST.GEORGE(a)leidos.com> wrote:
> I can confirm that I have the same issue on the hypervisor/nova-compute
> node that is hosting the instance...
>
> Chain neutron-openvswi-sd7933aba-f (1 references)
> num target prot opt source destination
> 1 RETURN all -- 10.0.0.6 0.0.0.0/0 MAC
> FA:16:3E:67:64:A4
> 2 DROP all -- 0.0.0.0/0 0.0.0.0/0
>
>
> How do we get someone to look at the problem for patching? This
> obviously wasn't identified and was carried over to the new build.
>
> - Allan
>
> ------------------------------
>
> Hi,
>
> I saw this issue too, I was just about to report it.
>
> If I understand correctly, this is because of the openvswitch iptables
> rules which are created (for security groups?)
>
> `service iptables status`
> ...
> Chain neutron-openvswi-s0ec3eb58-0 (1 references)
> num target prot opt source destination
> 1 RETURN all -- 10.0.0.12 0.0.0.0/0 MAC
> FA:16:3E:2E:B7:E3
> 2 DROP all -- 0.0.0.0/0 0.0.0.0/0
> ....
>
> In your case, the MAC address is different -- FA:16:3E:67:64:A4
>
> This issue also appears on icehouse w/ foreman, so it looks like it may
> be the puppet modules at fault here
>
> Andrew.
>
>
> On Fri, Mar 28, 2014 at 7:37 AM, St. George, Allan L. <
> ALLAN.L.ST.GEORGE(a)leidos.com> wrote:
>
>> Currently running RDO/Havana deployed via Foreman on a multi-compute
>> node stack (Controller, Neutron, and three Nova-Compute servers)
>>
>>
>>
>> When spawning an instance, it correctly spawns and reports/registers to
>> the Foreman dashboard.
>>
>>
>>
>> The problem is that the hypervisor/compute-node that is hosting the
>> instance will then begin to report:
>>
>>
>>
>> *Level*
>>
>> *Resource*
>>
>> *message*
>>
>> *err*
>>
>> Puppet
>>
>> Could not prefetch firewall provider 'iptables': Invalid address from
>> IPAddr.new: FA:16:3E:67:64:A4
>>
>> *err*
>>
>> /Firewall[001 nova compute incoming]
>>
>> Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4
>>
>> *err*
>>
>> /Firewall[002 vxlan udp]
>>
>> Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4
>>
>>
>>
>> When the instance is deleted, the error will disappear also.
>>
>>
>>
>> Any assistance/insight would be appreciated.
>>
>>
>>
>> Thank you.
>>
>> _______________________________________________
>> Rdo-list mailing list
>> Rdo-list(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>>
>
10 years
