[Rdo-list] Proposed Mitaka test days
by Rich Bowen
I'd like to propose the following test days for Mitaka. These are each
roughly a week after the various milestones.
At each test day, we'd be testing the Mitaka packages, if they are
available by that milestone. We'd also be doing "installfest" style
testing of the existing Liberty packages. And we'd also be doing
documentation testing/hacking alongside this.
Here's the dates. Please let me know whether any of these have any major
conflicts with national holidays or whatever. I've not put a November
date in here, but we can add one if desired.
Dec 10-11
Jan 27-28
Feb 18-19
Mar 10-11
Apr 13-14
Thoughts?
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://rdoproject.org/
9 years
[Rdo-list] shade client library
by Jeff Weber
Are there any plans to package the shade client library as part of RDO? We
are heavy users of Ansible and RDO and the Ansible OpenStack modules for
the upcoming 2.0 release have been being rewritten to depend on shade.
Having a version of shade packaged along with the other RDO packages in the
release would be quite useful.
If this is something where community participation would be helpful I'd be
happy to try to help out if someone had details on what would need to be
done.
9 years
[Rdo-list] [RDO-Manager] IBM H-Chassis install bare metal
by David Simmons
Hi,
I am installing RDO via RDO-Manager on a set of IBM H-Chassis blades. I need to configure the networking to perform the IPMI operations and PXE boot the overcloud nodes. The problem I am trying to solve is to get the chassis AMM to correctly route the IPMI/PXE operations to the blades. The IBM chassis requires all IPMI networking to use a VLAN that has been specified as the Chassis Internal Network. I have installed the undercloud on on blade on CentOS 7 and have been able to interact with the AMM and the blade IMMs on a vlan. Where I am running into problems is when the undercloud configuration occurs I am no longer able to interact on the specified VLAN and lose access to the Chassis AMM.
On each blade I have 4 network ports. 2 1G and 2 10G network switches. I have installed CentOS on the undercloud and use 1 1G port as the management. I have specified a 10G switch as the PXE/Management network. In the undercloud.conf file the 10G port is the port I have specified as the local interface.
To use the IPMI interface it has to tag all packets with the Chassis Internal Network VLAN. Are there any configuration tips that I can follow?
Thanks,
David Simmons
9 years
Re: [Rdo-list] Blueprint: Delorean & Khaleesi
by Arie Bregman
On Sat, Nov 7, 2015 at 12:07 AM, David Moreau Simard <dms(a)redhat.com> wrote:
> Can we extend this to rdo-list ? Sounds relevant to the community.
>
Sure, good idea. Adding rdo-list.
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Fri, Nov 6, 2015 at 4:36 PM, Wesley Hayutin <whayutin(a)redhat.com>
> wrote:
> > Arie,
> > This looks good.
> > Who is going to maintain the delorean ci job?
>
Who maintains it today? we'll have to discuss it. It might be good idea to
add 'job owner/maintainer' info as we have in rhos CI.
> Have you reached out to Derek Higgins about writing a replacement for the
> > current delorean ci?
>
No. The work on this has just begun. Adding Derek to this mail.
>
> > Thanks
> >
> > On Fri, Nov 6, 2015 at 11:21 AM, Steve Linabery <slinaber(a)redhat.com>
> wrote:
> >>
> >> On Fri, Nov 06, 2015 at 05:49:05PM +0200, Arie Bregman wrote:
> >> > Hi everyone,
> >> >
> >> > Not sure if you all familiar with Delorean project[1]. Quick
> >> > introduction
> >> > (CI related) for those who are not:
> >> >
> >> > Delorean is an upstream project that builds and maintains yum
> >> > repositories.
> >> > It builds repository every time patch submitted to one of the upstream
> >> > openstack-packages projects.
> >> > The delorean job is located here:
> >> > https://prod-rdojenkins.rhcloud.com/job/delorean-ci
> >> >
> >> > How the job works at the moment:
> >> > It runs delorean directly on the slave and if the build process
> >> > succeeded,
> >> > it votes with +1
> >> >
> >> > What I suggest:
> >> > - Move delorean installation and run to khaleesi by creating
> 'delorean'
> >> > role
> >> > - Extend the job to run tests using the rpms delorean built
> >> >
> >> > Why:
> >> > - Main reason: It's important for developers to get immediate feedback
> >> > on
> >> > whether the new packages are good or not. simply run delorean and see
> if
> >> > build is ok, is not enough. We need to extend the current job.
> >> >
> >> > - Users can use khaleesi to test specs they wrote. This is actually
> >> > pretty
> >> > amazing. users write specs and run khaleesi. khaleesi then handles
> >> > everything - it building the rpms using delorean and run the tests.
> >> >
> >> > - We can use delorean to replace our current way to build rpms and
> >> > creating
> >> > repos. delorean doing it in a smart way, using docker and by that it
> >> > creates rpms for several distributions in isolated environment.
> >>
> >> Delorean no longer uses docker.
> >>
> >>
> >>
> https://github.com/openstack-packages/delorean/commit/66571fce45a007bcf49...
>
Interesting. any idea why this change? adding Alan.
>
> >>
> >> >
> >> > - Khaleesi awesomeness will increase
> >> >
> >> > There is also no need to add/maintain settings in khaleesi for that.
> >> > delorean properties (version, url, etc) will be provided by extra-vars
> >> > (unless you are in favor of maintaining general settings for delorean
> in
> >> > khaleesi)
> >> >
> >> > The new job work flow:
> >> > 1. Run delorean on slave and save rpms from delorean build process.
> >> > 2. Run provision playbook
> >> > 3. Copy delorean rpms to provisioned nodes and create repo for them on
> >> > each
> >> > node
> >> > 4. run installer playbooks (installer will use delorean rpms)
> >> > 5. Run Tests =D
> >> > 6. Vote +1/-1 according to build process + tests.
> >> >
> >> > step 3 can be replaced. Since delorean creates repository, we can
> simply
> >> > reference each node to the new repository on the slave.
> >> >
> >> > Would love to hear your opinion on that.
> >> >
> >> > Cheers,
> >> >
> >> > Arie
> >> >
> >> > P.S
> >> > started to work on that: https://review.gerrithub.io/#/c/251464
> >> >
> >> > [1] https://github.com/openstack-packages/delorean
> >>
> >
>
9 years
Re: [Rdo-list] Cinder multi-backend (NetApp)
by Marius Cornea
Adding the list.
----- Original Message -----
> From: "Yogev Rabl" <yrabl(a)redhat.com>
> To: "Marius Cornea" <mcornea(a)redhat.com>
> Sent: Tuesday, November 10, 2015 11:11:45 AM
> Subject: Re: [Rdo-list] Cinder multi-backend (NetApp)
>
> Hi,
>
> If you're testing whether the second back end is ready for use, check the
> parameter enabled_backends in /etc/cinder/cinder.conf, its values are the
> section name of each back end.
> In addition, check whether a type was created for the second back end with
> the command
> # cinder extra-specs-list
>
> Cheers
>
>
> On Mon, Nov 9, 2015 at 6:53 PM, Marius Cornea <mcornea(a)redhat.com> wrote:
>
> > Hi Alessandro,
> >
> > Here are the steps for configuring Netapp as Cinder backend:
> >
> > https://repos.fedorapeople.org/repos/openstack-m/rdo-manager-docs/liberty...
> >
> > For deploying it together with Ceph I'd use the same steps for
> > /usr/share/openstack-tripleo-heat-templates/environments/puppet-ceph-external.yaml
> > and then deploy the overcloud by passing both the cinder-netapp-config.yaml
> > and puppet-ceph-external.yaml environment files:
> >
> > openstack overcloud deploy --templates -e ~/cinder-netapp-config.yaml -e
> > ~/puppet-ceph-external.yaml
> >
> > I haven't tried this scenario myself but it would be great to get some
> > feedback on it.
> >
> > Thanks,
> > Marius
> >
> > ----- Original Message -----
> > > From: "Alessandro Vozza" <alessandro(a)namecheap.com>
> > > To: "rdo-list" <rdo-list(a)redhat.com>
> > > Sent: Monday, November 9, 2015 5:32:39 PM
> > > Subject: [Rdo-list] Cinder multi-backend (NetApp)
> > >
> > >
> > > HI list
> > >
> > > how would you go about implementing multi backends in cinder via
> > > tripleo-templates? I know that upstream puppet modules supports it, but
> > how
> > > to specify a second backend (in particular, a NetApp+Ceph deployment)?
> > Any
> > > hint appreciated.
> > >
> > > P.S.
> > >
> > > I did find
> > >
> > https://github.com/openstack/tripleo-heat-templates/blob/master/environme...
> > > , but hot to enable dual backends?)
> > >
> > >
> > >
> > > _______________________________________________
> > > Rdo-list mailing list
> > > Rdo-list(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/rdo-list
> > >
> > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
> >
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
> >
>
>
>
> --
> Yogev Rabl
> Quality Engineer, Red Hat OSP - Storage
> +972-52-4534729
>
9 years
[Rdo-list] RDO-Manager HA Pacemaker in Compute Nodes
by Pedro Sousa
Hi all,
I would like to be able to recover automatically the VMS when a compute
node dies as described here:
http://blog.clusterlabs.org/blog/2015/openstack-ha-compute/
I've checked that I have pacemaker_remote.service
and NovaCompute/NovaEvacuate pacemaker resources on my compute nodes, but
it's doesn't seem to be configured/running:
[*root@overcloud-novacompute-0 openstack]# systemctl list-unit-files | grep
pacemaker*
*pacemaker.service disabled*
*pacemaker_remote.service disabled*
*[root@overcloud-novacompute-0 openstack]# pcs status*
*Error: cluster is not currently running on this node*
Is there a way to activate this on stack deployment? Or do I have to
customize it?
Thanks,
Pedro Sousa
9 years
[Rdo-list] RDO blogs roundup, week of November 9
by Rich Bowen
Here's what RDO enthusiasts were blogging about this week. If you were
at OpenStack Summit in Tokyo last month, don't forget to write up your
experience.
RDO Liberty released in CentOS Cloud SIG, by Alan Pevec
We are pleased to announce the general availability of the RDO
build for OpenStack Liberty for CentOS Linux 7 x86_64, suitable for
building private, public and hybrid clouds. OpenStack Liberty is the
12th release of the open source software collaboratively built by a
large number of contributors around the OpenStack.org project space.
… read more at http://tm3.org/3d
Neutron HA Talk in Tokyo Summit by Assaf Muller
Florian Haas, Adam Spiers and myself presented a session in Tokyo
about Neutron high availability. We talked about:
… read more at http://tm3.org/3s
OpenStack Summit Tokyo by Matthias Runge
Over the past week, I attended the OpenStack Summit in Tokyo. My
primary focus was on Horizon sessions. Nevertheless, I was lucky to
have one or two glimpses at more touristic spots in Tokyo.
… read more at http://tm3.org/3t
OpenStack Summit Tokyo – Final Summary by Gordon Tillmore
As I flew home from OpenStack Summit Tokyo last week, I had plenty
of time to reflect on what proved to be a truly special event.
OpenStack gains more and more traction and maturity with each
community release and corresponding Summit, and the 11th semi-annual
OpenStack Summit certainly did not disappoint. With more than 5,000
attendees, it was the largest ever OpenStack Summit outside of North
America, and there were so many high quality keynotes, session, and
industry announcements, I thought it made sense to put together a
final trip overview, detailing all of the noteworthy news, Red Hat
press releases, and more.
… read more at http://tm3.org/3u
Community Meetup at OpenStack Tokyo by Rich Bowen
A week ago in Tokyo, we held the third RDO Community Meetup at the
OpenStack Summit. We had about 70 people in attendance, and some good
discussion. The full agenda for the meeting is at
https://etherpad.openstack.org/p/rdo-tokyo and below are some of the
things that were discussed. (The complete recording is at the bottom
of this post.)
… read more at http://tm3.org/3v
Mike Perez: Cinder in Liberty by Rich Bowen
Before OpenStack Summit, I interviewed Mike Perez about what's new
in Cinder in the LIberty release, and what's coming in Mitaka.
Unfortunately, life got a little busy and I didn't get it posted
before Summit. However, with Liberty still fresh, this is still very
timely content.
… read more at http://tm3.org/3w
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://rdoproject.org/
9 years
