September 30, 2014

Michael Still

Blueprints implemented in Nova during Juno

As we get closer to releasing the RC1 of Nova for Juno, I've started collecting a list of all the blueprints we implemented in Juno. This was mostly done because it helps me write the release notes, but I am posting it here because I am sure that others will find it handy too.

Process

  • Reserve 10 sql schema version numbers for back ports of Juno migrations to Icehouse. launchpad specification


Ongoing behind the scenes work

Object conversion

Scheduler
  • Support sub-classing objects. launchpad specification
  • Stop using the scheduler run_instance method. Previously the scheduler would select a host, and then boot the instance. Instead, let the scheduler select hosts, but then return those so the caller boots the instance. This will make it easier to move the scheduler to being a generic service instead of being internal to nova. launchpad specification
  • Refactor the nova scheduler into being a library. This will make splitting the scheduler out into its own service later easier. launchpad specification
  • Move nova to using the v2 cinder API. launchpad specification
  • Move prep_resize to conductor in preparation for splitting out the scheduler. launchpad specification


API
  • Use JSON schema to strongly validate v3 API request bodies. Please note this work will later be released as v2.1 of the Nova API. launchpad specification
  • Provide a standard format for the output of the VM diagnostics call. This work will be exposed by a later version of the v2.1 API. launchpad specification
  • Move to the OpenStack standard name for the request id header, in a backward compatible manner. launchpad specification
  • Implement the v2.1 API on the V3 API code base. This work is not yet complete. launchpad specification


Other
  • Refactor the internal nova API to make the nova-network and neutron implementations more consistent. launchpad specification


General features

Instance features

Networking

Scheduling
  • Extensible Resource Tracking. The set of resources tracked by nova is hard coded, this change makes that extensible, which will allow plug-ins to track new types of resources for scheduling. launchpad specification
  • Allow a host to be evacuated, but with the scheduler selecting destination hosts for the instances moved. launchpad specification
  • Add support for host aggregates to scheduler filters. launchpad specification


Other
  • i18n Enablement for Nova, turn on the lazy translation support from Oslo i18n and updating Nova to adhere to the restrictions this adds to translatable strings. launchpad specification
  • Offload periodic task sql query load to a slave sql server if one is configured. launchpad specification
  • Only update the status of a host in the sql database when the status changes, instead of every 60 seconds. launchpad specification
  • Include status information in API listings of hypervisor hosts. launchpad specification
  • Allow API callers to specify more than one status to filter by when listing services. launchpad specification
  • Add quota values to constrain the number and size of server groups a users can create. launchpad specification


Hypervisor driver specific

Hyper-V

Ironic

libvirt

vmware
  • Move the vmware driver to using the oslo vmware helper library. launchpad specification
  • Add support for network interface hot plugging to vmware. launchpad specification
  • Refactor the vmware driver's spawn functionality to be more maintainable. This work was internal, but is mentioned here because it significantly improves the supportability of the VMWare driver. launchpad specification


Tags for this post: openstack juno blueprints implemented

Comment

September 30, 2014 01:05 PM

OpenStack Blog

Telcos Mobilizing to Drive NFV Adoption

Today the Linux Foundation announced the Open Platform for NFV (OPNFV) Project, a group comprised primarily of telco operators working across open source projects and vendors to implement Network Functions Virtualization (NFV) within their organizations. This is an exciting development because the market is growing quickly, and many OpenStack community members are also participating in OPNFV, giving us an opportunity to collaborate closely with another like-minded open source Foundation. User input is critical at this stage of a technology shift as significant as NFV will be for telco and even enterprise networks, and any organization that is willing to contribute knowledge and code to those efforts is welcome in the OpenStack community.

Much work has been done to build in support for NFV by the OpenStack community. Mark Lambe of SDN Central said on September 8, 2014:

Network functions virtualization (NFV) is now synonymous with OpenStack. When people say NFV, there is an implication that they are talking about OpenStack.”

Why is that? The open, modular and interoperable framework of the OpenStack project simplifies software. This flexibility is apparent in the OpenStack Networking component that features drivers and plug-ins from numerous leading telco vendors. Working through a project like OpenStack Networking, users do not have to worry about altering their APIs or modifying code if they decide to switch the underlying implementation technology. Much of the early interest surrounding NFV also led to updates in the OpenStack Compute component to meet the demanding requirements of the world’s leading operators.

After our OpenStack Summit in May, an NFV community team formed to accelerate development around NFV-specific features. Led by community member and former compute Program Technical Leader Russell Bryant, the group includes telco giants AT&T and Verizon as well as operators like Telefonica, Orange, and Portugal Telecom, and technology companies such as Ericsson, Huawei, Intel, Red Hat, Canonical, Alcatel Lucent, Mirantis, eNovance, Wipro, Wind River, Cisco, NEC, Juniper, VMware, Mellanox, HP, and more. For more information on the technical progress being made to support NFV you can read Russell’s blog post on this topic. The momentum surrounding NFV continues as we gear up for the Juno software release and OpenStack Summit Paris, where NFV-related topics and panels will dominate our telco strategies programming track. We hope to see you soon in Paris to continue our NFV work and conversation November 3 – 7, 2014.

OpenStack Summit Paris NFV presentations and panels:

Previous OpenStack Summit NFV Talks of Note:

<object height="315" width="560"><param name="movie" value="//www.youtube.com/v/eeaTQsZdxHE?version=3&amp;hl=en_US&amp;rel=0"/><param name="allowFullScreen" value="true"/><param name="allowscriptaccess" value="always"/><embed allowfullscreen="true" allowscriptaccess="always" height="315" src="//www.youtube.com/v/eeaTQsZdxHE?version=3&amp;hl=en_US&amp;rel=0" type="application/x-shockwave-flash" width="560"></embed></object>

by OpenStack at September 30, 2014 12:09 PM

Opensource.com

Humanitarian applications in OpenStack, the Rosetta Stone of the cloud, and more

Interested in keeping track of what's happening in the open source cloud? Opensource.com is your source for what's happening right now in OpenStack, the open source cloud infrastructure project.

by Jason Baker at September 30, 2014 05:00 AM

Michael Still

My candidacy for Kilo Compute PTL

This is mostly historical at this point, but I forgot to post it here when I emailed it a week or so ago. So, for future reference:

I'd like another term as Compute PTL, if you'll have me.

We live in interesting times. openstack has clearly gained a large
amount of mind share in the open cloud marketplace, with Nova being a
very commonly deployed component. Yet, we don't have a fantastic
container solution, which is our biggest feature gap at this point.
Worse -- we have a code base with a huge number of bugs filed against
it, an unreliable gate because of subtle bugs in our code and
interactions with other openstack code, and have a continued need to
add features to stay relevant. These are hard problems to solve.

Interestingly, I think the solution to these problems calls for a
social approach, much like I argued for in my Juno PTL candidacy
email. The problems we face aren't purely technical -- we need to work
out how to pay down our technical debt without blocking all new
features. We also need to ask for understanding and patience from
those feature authors as we try and improve the foundation they are
building on.

The specifications process we used in Juno helped with these problems,
but one of the things we've learned from the experiment is that we
don't require specifications for all changes. Let's take an approach
where trivial changes (no API changes, only one review to implement)
don't require a specification. There will of course sometimes be
variations on that rule if we discover something, but it means that
many micro-features will be unblocked.

In terms of technical debt, I don't personally believe that pulling
all hypervisor drivers out of Nova fixes the problems we face, it just
moves the technical debt to a different repository. However, we
clearly need to discuss the way forward at the summit, and come up
with some sort of plan. If we do something like this, then I am not
sure that the hypervisor driver interface is the right place to do
that work -- I'd rather see something closer to the hypervisor itself
so that the Nova business logic stays with Nova.

Kilo is also the release where we need to get the v2.1 API work done
now that we finally have a shared vision for how to progress. It took
us a long time to get to a good shared vision there, so we need to
ensure that we see that work through to the end.

We live in interesting times, but they're also exciting as well.


I have since been elected unopposed, so thanks for that!

Tags for this post: openstack kilo compute ptl
Related posts: Juno Nova PTL Candidacy; Review priorities as we approach juno-3; Thoughts from the PTL; Havana Nova PTL elections; Expectations of core reviewers

Comment

September 30, 2014 02:34 AM

David Moreau Simard

S3QL, a filesystem over HTTP with Swift

Swift and Object Storage

Swift is Openstack‘s Object Storage project.

At a very high level, I like to present Object Storage as a filesystem accessible through a set of APIs, often directly by HTTP.

Object Storage backends are usually built from the ground up to be resilient, failure tolerant, highly available and provide mechanisms to ensure data redundancy and security.

Object Storage is the secret sauce that hides behind interfaces such as Dropbox, Google Drive or Microsoft OneDrive.

Ceph is another open source project with Object Storage at it’s core. Ceph natively provides a way to create, mount and format block devices out of the box - Swift, however, does not.

This is great and I’m a fan of Ceph myself but what if there was a way to mount a Swift object store as a filesytem ?

Let’s take a closer look at S3QL which allows you to do just that.

If you don’t have an object storage service, I’ve written a basic guide on finding the right provider.

What’s S3QL ?

Straight from S3QL’s repository:

S3QL is a file system that stores all its data online using storage services like Google Storage, Amazon S3, or OpenStack. S3QL effectively provides a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X.

S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival.

Sounds pretty neat, right ? Let’s see if we can get it installed and test it out.

Installing S3QL

Thankfully, S3QL is packaged for most distributions because it is otherwise a bit more complex to install.

I’ll be testing this under Ubuntu 14.04 (Trusty) so it’s really as simple as adding the PPA and installing S3QL:

add-apt-repository ppa:nikratio/s3ql
apt-get update && apt-get -y install s3ql

Setting it up

Authentication

First, create the file in which you’ll store authentication details:

mkdir ~/.s3ql && install -b -m 600 /dev/null ~/.s3ql/authinfo2

Open up ~/.s3ql/authinfo2 with your favorite editor and fill in your Swift authentication information in the following format:

[swift]
backend-login: tenant:username
backend-password: password
storage-url: swiftks://keystone.example.org/<region>:<container>

It was not necessary for me to specify whether or not the keystone is HTTPs (port 443) and also the (/v2.0|/v2.0/tokens) portion of the authentication URL.

The <region> parameter is something that depends on your provider and where your data is located.

The <container> is the bucket in which the filesystem will reside. It needs to be created first, s3ql won’t do it for you.

Creating the Swift container for s3ql

To create an empty container with swiftclient, you can use swift post <container>:

# Create an empty container called "s3ql" if it doesn't exist
$ swift post s3ql
$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 0
         Bytes: 0
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: tx3e99ab36fdf44fa3b197f-00542a07bc
  Content-Type: text/html; charset=UTF-8

Initializing the filesystem

To initialize the filesystem, use mkfs.s3ql with your storage url as argument:

$ mkfs.s3ql swiftks://keystone.example.org/region:s3ql
Before using S3QL, make sure to read the user's guide, especially
the 'Important Rules to Avoid Loosing Data' section.
Enter encryption password:
Confirm encryption password:
Generating random encryption key...
Creating metadata tables...
Dumping metadata...
..objects..
..blocks..
..inodes..
..inode_blocks..
..symlink_targets..
..names..
..contents..
..ext_attributes..
Compressing and uploading metadata...
Wrote 155 bytes of compressed metadata.

We can tell that s3ql created some objects:

$ swift list s3ql
s3ql_metadata
s3ql_passphrase
s3ql_passphrase_bak1
s3ql_passphrase_bak2
s3ql_passphrase_bak3
s3ql_seq_no_1
$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 6
         Bytes: 791
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: txddafca8cbda244f5b5f1e-00542a0944
  Content-Type: text/plain; charset=utf-8

Mounting the filesystem

s3ql provides the mount.s3ql utility that’s pretty straightforward:

$ mkdir /mnt/s3ql
$ mount.s3ql swiftks://keystone.example.org/region:s3ql /mnt/s3ql/
Using 4 upload threads.
Autodetected 4052 file descriptors available for cache entries
Enter file system encryption passphrase:
Using cached metadata.
Setting cache size to 37584 MB
Mounting filesystem...
$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.1G   46G   3% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T     0  1.0T   0% /mnt/s3ql
$ ls -al /mnt/s3ql/
total 0
drwx------ 1 root root 0 Sep 29 21:32 lost+found

Cool.

Trying it out

$ dd if=/dev/zero of=/mnt/s3ql/bigfile.bin bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 80.1757 s, 13.4 MB/s

So, pretty much as fast as my upload speed will go ?

What does it look like on Swift’s side ?

$ swift list s3ql --lh
1.7K 2014-09-30 01:47:25 s3ql_data_1
 792 2014-09-30 01:48:45 s3ql_data_2
 155 2014-09-30 01:32:34 s3ql_metadata
 132 2014-09-30 01:32:34 s3ql_passphrase
 132 2014-09-30 01:32:34 s3ql_passphrase_bak1
 132 2014-09-30 01:32:34 s3ql_passphrase_bak2
 132 2014-09-30 01:32:34 s3ql_passphrase_bak3
 108 2014-09-30 01:32:35 s3ql_seq_no_1
 108 2014-09-30 01:39:42 s3ql_seq_no_2
3.3K

Oh, what’s this. Where’s my 1GB file ? Nothing’s being uploaded in the background.

Unmounting and re-mounting the filesystem, still nothing in Swift.. but my file is there, so it has to be stored somewhere, right ?

$ ls -alh /mnt/s3ql/
total 1.0G
-rw-r--r-- 1 root root 1.0G Sep 29 21:48 bigfile.bin
drwx------ 1 root root    0 Sep 29 21:32 lost+found

Pleasant surprises

That’s right, s3ql provides data compression and de-duplication out of the box. I have a 1GB file but it’s all zeroes so it compresses really well.

Let’s download an ISO file and see what happens:

$ wget http://releases.ubuntu.com/14.04.1/ubuntu-14.04.1-server-amd64.iso -O /mnt/s3ql/ubuntu-14.04.1-server-amd64.iso

Once the download completed, I could see the space started being used up slowly until most of the space taken by the ISO was there:

$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.7G   46G   4% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T  194M  1.0T   1% /mnt/s3ql

$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.7G   46G   4% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T  586M  1.0T   1% /mnt/s3ql

And then querying Swift I could finally see some objects:

$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 72
         Bytes: 582715279
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: tx26300dd0f2bf411da158a-00542a10bb
  Content-Type: text/plain; charset=utf-8

$ swift list --lh s3ql
1.7K 2014-09-30 01:47:25 s3ql_data_1
10.0M 2014-09-30 02:01:09 s3ql_data_10
9.3M 2014-09-30 02:01:23 s3ql_data_11
10.0M 2014-09-30 02:01:29 s3ql_data_12
[...]
9.9M 2014-09-30 02:01:06 s3ql_data_8
9.3M 2014-09-30 02:01:00 s3ql_data_9
 375 2014-09-30 01:54:18 s3ql_metadata
 155 2014-09-30 01:54:17 s3ql_metadata_bak_0
 155 2014-09-30 01:54:17 s3ql_metadata_bak_0_tmp$oentuhuo23986konteuh1062$
 375 2014-09-30 01:54:15 s3ql_metadata_new
 375 2014-09-30 01:54:17 s3ql_metadata_tmp$oentuhuo23986konteuh1062$
 132 2014-09-30 01:32:34 s3ql_passphrase
 132 2014-09-30 01:32:34 s3ql_passphrase_bak1
 132 2014-09-30 01:32:34 s3ql_passphrase_bak2
 132 2014-09-30 01:32:34 s3ql_passphrase_bak3
 108 2014-09-30 01:32:35 s3ql_seq_no_1
 108 2014-09-30 01:39:42 s3ql_seq_no_2
 108 2014-09-30 01:54:59 s3ql_seq_no_3
555M

In conclusion

It works, and it works pretty well from what I’ve seen so far.

I’ve recently written a post on how you could encrypt your backups and send them to a Swift object storage with duplicity.

s3ql also encrypts your data with a passphrase, preventing a third party to peek at your data.

I still think duplicity is great since it really keeps track of your backups and is very efficient in doing so.

I don’t have a great use case that comes to mind right now for s3ql but I’m sure users will find out as object storage becomes cheaper and cheaper.

by dmsimard at September 30, 2014 02:00 AM

S3QL, a filesystem over HTTP with Openstack Swift

Swift and Object Storage

Swift is Openstack‘s Object Storage project.

At a very high level, I like to present Object Storage as a filesystem accessible through a set of APIs, often directly by HTTP.

Object Storage backends are usually built from the ground up to be resilient, failure tolerant, highly available and provide mechanisms to ensure data redundancy and security.

Object Storage is the secret sauce that hides behind interfaces such as Dropbox, Google Drive or Microsoft OneDrive.

Ceph is another open source project with Object Storage at it’s core. Ceph natively provides a way to create, mount and format block devices out of the box - Swift, however, does not.

This is great and I’m a fan of Ceph myself but what if there was a way to mount a Swift object store as a filesytem ?

Let’s take a closer look at S3QL which allows you to do just that.

If you don’t have an object storage service, I’ve written a basic guide on finding the right provider.

What’s S3QL ?

Straight from S3QL’s repository:

S3QL is a file system that stores all its data online using storage services like Google Storage, Amazon S3, or OpenStack. S3QL effectively provides a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X.

S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival.

Sounds pretty neat, right ? Let’s see if we can get it installed and test it out.

Installing S3QL

Thankfully, S3QL is packaged for most distributions because it is otherwise a bit more complex to install.

I’ll be testing this under Ubuntu 14.04 (Trusty) so it’s really as simple as adding the PPA and installing S3QL:

add-apt-repository ppa:nikratio/s3ql
apt-get update && apt-get -y install s3ql

Setting it up

Authentication

First, create the file in which you’ll store authentication details:

mkdir ~/.s3ql && install -b -m 600 /dev/null ~/.s3ql/authinfo2

Open up ~/.s3ql/authinfo2 with your favorite editor and fill in your Swift authentication information in the following format:

[swift]
backend-login: tenant:username
backend-password: password
storage-url: swiftks://keystone.example.org/<region>:<container>

It was not necessary for me to specify whether or not the keystone is HTTPs (port 443) and also the (/v2.0|/v2.0/tokens) portion of the authentication URL.

The <region> parameter is something that depends on your provider and where your data is located.

The <container> is the bucket in which the filesystem will reside. It needs to be created first, s3ql won’t do it for you.

Creating the Swift container for s3ql

To create an empty container with swiftclient, you can use swift post <container>:

# Create an empty container called "s3ql" if it doesn't exist
$ swift post s3ql
$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 0
         Bytes: 0
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: tx3e99ab36fdf44fa3b197f-00542a07bc
  Content-Type: text/html; charset=UTF-8

Initializing the filesystem

To initialize the filesystem, use mkfs.s3ql with your storage url as argument:

$ mkfs.s3ql swiftks://keystone.example.org/region:s3ql
Before using S3QL, make sure to read the user's guide, especially
the 'Important Rules to Avoid Loosing Data' section.
Enter encryption password:
Confirm encryption password:
Generating random encryption key...
Creating metadata tables...
Dumping metadata...
..objects..
..blocks..
..inodes..
..inode_blocks..
..symlink_targets..
..names..
..contents..
..ext_attributes..
Compressing and uploading metadata...
Wrote 155 bytes of compressed metadata.

We can tell that s3ql created some objects:

$ swift list s3ql
s3ql_metadata
s3ql_passphrase
s3ql_passphrase_bak1
s3ql_passphrase_bak2
s3ql_passphrase_bak3
s3ql_seq_no_1
$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 6
         Bytes: 791
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: txddafca8cbda244f5b5f1e-00542a0944
  Content-Type: text/plain; charset=utf-8

Mounting the filesystem

s3ql provides the mount.s3ql utility that’s pretty straightforward:

$ mkdir /mnt/s3ql
$ mount.s3ql swiftks://keystone.example.org/region:s3ql /mnt/s3ql/
Using 4 upload threads.
Autodetected 4052 file descriptors available for cache entries
Enter file system encryption passphrase:
Using cached metadata.
Setting cache size to 37584 MB
Mounting filesystem...
$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.1G   46G   3% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T     0  1.0T   0% /mnt/s3ql
$ ls -al /mnt/s3ql/
total 0
drwx------ 1 root root 0 Sep 29 21:32 lost+found

Cool.

Trying it out

$ dd if=/dev/zero of=/mnt/s3ql/bigfile.bin bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 80.1757 s, 13.4 MB/s

So, pretty much as fast as my upload speed will go ?

What does it look like on Swift’s side ?

$ swift list s3ql --lh
1.7K 2014-09-30 01:47:25 s3ql_data_1
 792 2014-09-30 01:48:45 s3ql_data_2
 155 2014-09-30 01:32:34 s3ql_metadata
 132 2014-09-30 01:32:34 s3ql_passphrase
 132 2014-09-30 01:32:34 s3ql_passphrase_bak1
 132 2014-09-30 01:32:34 s3ql_passphrase_bak2
 132 2014-09-30 01:32:34 s3ql_passphrase_bak3
 108 2014-09-30 01:32:35 s3ql_seq_no_1
 108 2014-09-30 01:39:42 s3ql_seq_no_2
3.3K

Oh, what’s this. Where’s my 1GB file ? Nothing’s being uploaded in the background.

Unmounting and re-mounting the filesystem, still nothing in Swift.. but my file is there, so it has to be stored somewhere, right ?

$ ls -alh /mnt/s3ql/
total 1.0G
-rw-r--r-- 1 root root 1.0G Sep 29 21:48 bigfile.bin
drwx------ 1 root root    0 Sep 29 21:32 lost+found

Pleasant surprises

That’s right, s3ql provides data compression and de-duplication out of the box. I have a 1GB file but it’s all zeroes so it compresses really well.

Let’s download an ISO file and see what happens:

$ wget http://releases.ubuntu.com/14.04.1/ubuntu-14.04.1-server-amd64.iso -O /mnt/s3ql/ubuntu-14.04.1-server-amd64.iso

Once the download completed, I could see the space started being used up slowly until most of the space taken by the ISO was there:

$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.7G   46G   4% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T  194M  1.0T   1% /mnt/s3ql

$ df -h
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vda1                                    50G  1.7G   46G   4% /
none                                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                                        991M   12K  991M   1% /dev
tmpfs                                       201M  352K  200M   1% /run
none                                        5.0M     0  5.0M   0% /run/lock
none                                       1001M     0 1001M   0% /run/shm
none                                        100M     0  100M   0% /run/user
swiftks://keystone.example.org/region:s3ql  1.0T  586M  1.0T   1% /mnt/s3ql

And then querying Swift I could finally see some objects:

$ swift stat s3ql
       Account: AUTH_e8217e83ef32427bb4e4d217f1390ab4
     Container: s3ql
       Objects: 72
         Bytes: 582715279
      Read ACL:
     Write ACL:
       Sync To:
      Sync Key:
 Accept-Ranges: bytes
        Server: nginx
    Connection: keep-alive
   X-Timestamp: 1412040138.20837
    X-Trans-Id: tx26300dd0f2bf411da158a-00542a10bb
  Content-Type: text/plain; charset=utf-8

$ swift list --lh s3ql
1.7K 2014-09-30 01:47:25 s3ql_data_1
10.0M 2014-09-30 02:01:09 s3ql_data_10
9.3M 2014-09-30 02:01:23 s3ql_data_11
10.0M 2014-09-30 02:01:29 s3ql_data_12
[...]
9.9M 2014-09-30 02:01:06 s3ql_data_8
9.3M 2014-09-30 02:01:00 s3ql_data_9
 375 2014-09-30 01:54:18 s3ql_metadata
 155 2014-09-30 01:54:17 s3ql_metadata_bak_0
 155 2014-09-30 01:54:17 s3ql_metadata_bak_0_tmp$oentuhuo23986konteuh1062$
 375 2014-09-30 01:54:15 s3ql_metadata_new
 375 2014-09-30 01:54:17 s3ql_metadata_tmp$oentuhuo23986konteuh1062$
 132 2014-09-30 01:32:34 s3ql_passphrase
 132 2014-09-30 01:32:34 s3ql_passphrase_bak1
 132 2014-09-30 01:32:34 s3ql_passphrase_bak2
 132 2014-09-30 01:32:34 s3ql_passphrase_bak3
 108 2014-09-30 01:32:35 s3ql_seq_no_1
 108 2014-09-30 01:39:42 s3ql_seq_no_2
 108 2014-09-30 01:54:59 s3ql_seq_no_3
555M

In conclusion

It works, and it works pretty well from what I’ve seen so far.

I’ve recently written a post on how you could encrypt your backups and send them to a Swift object storage with duplicity.

s3ql also encrypts your data with a passphrase, preventing a third party to peek at your data.

I still think duplicity is great since it really keeps track of your backups and is very efficient in doing so.

I don’t have a great use case that comes to mind right now for s3ql but I’m sure users will find out as object storage becomes cheaper and cheaper.

by dmsimard at September 30, 2014 02:00 AM

September 29, 2014

Cloud Platform @ Symantec

How to configure and run Tempest for testing OpenStack Keystone Identity V3 API?

Prerequisite: Please make sure you have an OpenStack IceHouse instance and configured it with Keystone V3. Also, my experimental OpenStack instance has cloud_admin set in policy.json as:

"cloud_admin": "rule:admin_required and domain_id:default",

Get the latest tempest resources from GitHub:

Screen Shot 2014-09-29 at 12.54.44 PM.png

Create a configuration file “tempest/etc/tempest.conf” for tempest using the sample file from “tempest/etc/tempest.conf.sample”. 

Screen Shot 2014-09-29 at 12.56.28 PM.png

Sample configuration file has all the configurations commented out. Here is the list of all required configuration options for running testing identity V3 API:

[idenitity]

# Full URI of the OpenStack Identity API (Keystone), v2
uri=http://10.0.2.15:5000/v2.0/

# Full URI of the OpenStack Identity API (Keystone), v3
uri_v3=http://10.0.2.15:5000/v3/

# Identity API version to be used for authentication for API tests.
auth_version=v3

# Admin username 
username=admin

# API key to use when authenticating.
password=openstack

# Domain name for authentication (Keystone V3).The same domain
# applies to user and project.
domain_name=Default

# Role required to administrate keystone.
admin_role=admin

# Administrative Username to use for Keystone API requests.
admin_username=admin

# API key to use when authenticating as admin.
admin_password=openstack

# Admin domain name for authentication (Keystone V3).The same
# domain applies to user and project.
admin_domain_name=Default

# The endpoint type to use for the identity service.
endpoint_type=publicURL

# Catalog type of the Identity service.
catalog_type=identity

[identity-feature-enabled]

# Is the v3 identity API enabled (boolean value)
api_v3=true

Always run tests in virtualenv which is created automatically with all the necessary dependencies with run_tempest.sh script.

Screen Shot 2014-09-29 at 1.01.44 PM.png

Ideally, the latest tempest test cases from github should be executed successfully. But I was running into few permissions issues. I modified few tempest source files and here is the list of changes I made:

CHANGE-01: tempest/tempest/services/identity/v3/json/identity_client.py

Updated def auth() from V3TokenClientJSON class:

Original:

        if tenant is not None:
            _domain = dict(name=domain)
            project = dict(name=tenant, domain=_domain)
            scope = dict(project=project)
            creds['auth']['scope'] = scope

Changed to:

        if tenant is not None:
            _domain = dict(name=domain)
            scope = dict(domain=_domain)
            creds['auth']['scope'] = scope

Rationale: This change is modifying scope of a token. Setting the token scope to domain level instead of project level. For admin operations like creating/updating/deleting projects, creating/updating users, authentication token should have domain level scope. This might not be the ideal fix as token scope is changed and set to domain level for all test cases. The same reason applies to the following change.

Also, notice that we have not specified tenant_name and admin_tenant_name in tempest.conf which are mandatory without these changes.

CHANGE-02: tempest/tempest/services/identity/v3/xml/identity_client.py

Updated def auth() from V3TokenClientXML class:

Original:

        if tenant is not None:
            project = common.Element('project', name=tenant)
            _domain = common.Element('domain', name=domain)
            project.append(_domain)
            scope = common.Element('scope')
            scope.append(project)
            auth.append(scope)

Changed to:

        if tenant is not None:
            _domain = common.Element('domain', name=domain)
            scope = common.Element('scope')
            scope.append(_domain)
            auth.append(scope)

CHANGE-03: tempest/tempest /auth.py

Updated def _fill_credentials() from KeystoneV3AuthProvider class.

Original:

if domain is not None:
            if self.credentials.domain_id is None:
                self.credentials.domain_id = domain['id']
            if self.credentials.domain_name is None:
                self.credentials.domain_name = domain['name']

Changed to:

if domain is not None:
            if self.credentials.user_domain_id is None:
                self.credentials.user_domain_id = domain['id']
            if self.credentials.user_domain_name is None:
                self.credentials.user_domain_name = domain['name']

Rationale: After changing scope of authentication tokens, credentials object is changed to use appropriate attributes, user_domain_id and user_domain_name.

CHANGE-04: tempest/tempest/api/identity/base.py

Updated def _try_wrapper() from DataGenerator class.

Original:

           try:
                if kwargs:
                    func(item['id'], kwargs)

Changed to:

           try:
                if kwargs:
                    func(item['id'], **kwargs)

Rationale: This function has typo and kwargs should be passed as a packed dictionary. I have a Launchpad bug created for this change here.

Now, try and execute tempest test cases with run_tempest.sh:

Screen Shot 2014-09-29 at 2.07.19 PM.png

Screen Shot 2014-09-29 at 2.07.36 PM.png

You can also run tests in debug mode using –d option, like:

./run_tempest.sh -d tempest.api.identity.admin.v3.test_domains

Good luck with Tempest and Keystone V3 !

by Priti_Desai at September 29, 2014 09:52 PM

Mirantis

Tell us how you use OpenStack: the OpenStack User Survey

Anecdotal information is nice, but there’s nothing like a good user study to tell us what’s really going on in the OpenStack industry.  Every six months, the OpenStack Foundation launches the OpenStack User Survey, releasing the results at the OpenStack Summit.  The latest survey launched this week, with the results to be announced at the OpenStack Summit in Paris in November.

The survey addresses topics such as what deployment tools are in use, what OpenStack releases are in play, and for what (for example, production versus proof of concept), and operating systems being used.  This survey also touches on topics of current interest, such as developer issues (asking what development languages respondents used to interact with the OpenStack API) and hybrid cloud (asking what other systems respondents interact with).

In the spring of 2014, results showed that more than half (53%) of the 506 deployments shown were at companies with more than 100 employees, and almost a quarter (24%) are at enterprises with more than 5000 employees.  Large deployments were also starting to show, with almost 20% of deployments serving more than 1,000 instances, and 9 deployments showing more than 10,000 instances. The top business driver was avoiding vendor lock-in, with cost-savings and operational efficiency right behind.  In addition, the survey showed a larger influence from Operators, with an emphasis on giving them a larger role in future versions.

The OpenStack community values these results as a way to make sure that we’re heading in the right direction, so please take a moment to respond to the current OpenStack User Survey for yourself at the OpenStack Foundation’s website.  The deadline for responses is October 6, 2014.

The post Tell us how you use OpenStack: the OpenStack User Survey appeared first on Mirantis | The #1 Pure Play OpenStack Company.

by Alex Freedland at September 29, 2014 08:05 PM

IBM OpenStack Team

The benefits of integrating your own CI environment into OpenStack

In a previous post, I provided an overview of the processes and tools used for continuous integration in OpenStack. Here I’d like to take a moment to talk about the benefits of creating and integrating your own continuous integration (CI) environment into OpenStack.

Why would you create your own CI environment if OpenStack already has one available?

The first reason involves your own components and systems. OpenStack projects, Tempest tests and DevStack can accomplish very broad tasks.. However, some components depend on physical characteristics such as the architecture, operating system (including specific distributions) and hypervisor in order to run tests. For instance, if you need integration for a PowerKVM hypervisor, you need PowerKVM in your environment. A distribution may want to test OpenStack against the different versions of their system and a network card manufacturer may ensure Neutron will not break on their cards.

The services for CI (Zuul, Jenkins, Nodepool) used by the OpenStack Infrastructure community are widely accessible, therefore they can be used to build your own environment.

Let’s talk in general about the tools, knowledge and skills you’ll need in order to do this.

What do you need in your environment?

Basically, you will need a cloud environment (OpenStack cloud, of course) with the components and systems you want to test. If you are using PowerKVM as your hypervisor, you’ll need a Power-based cloud with PowerKVM installed on each of the nodes. You’ll also need a pool of servers (such as virtual machines outside or inside the cloud) where you are going to install the services you need.

How large should it be?

First, think about which OpenStack projects you want to check and how many types of jobs you will run. Suppose you are going to verify tests against Nova and you want to cover unit tests, Tempest tests against MySQL, and PostgreSQL. That makes three different sets of tests you want to run. You can get a better understanding of those by looking at a patch review in Gerrit. For example, you may see the following:

Openstack testJobs running on official OpenStack CI by Jenkins—source: http://review.openstack.org

If you want to check every patch submitted for those three jobs, you will need enough VMs to run those checks. Considering we have an average of 90 patch sets for Nova per day, each will run three jobs, and the average duration (considering failures) would be 90 minutes.

In a Gaussian distribution, at our peak, we would need around 50 virtual machines to consecutively run the jobs needed. Since we have the Zuul service that will handle the queue of changes, we don’t need to consider the peak, but that can give us an idea of the size of the cloud we need. The duration of jobs can also change according to the third-party components being tested. The closer this is to the actual community values, the better.

Openstack test summary

Source:  http://stackalytics.com/report/contribution/nova-group/30

In the next and final post of this series, I will talk about the main services used for continuous integration and how you can put it all together. I will also point out some tutorials for next steps.

Can you think of any other considerations when creating your own CI environment? Feel free to contact me on Twitter  or LinkedIn, or leave a comment below to continue the conversation.

The post The benefits of integrating your own CI environment into OpenStack appeared first on Thoughts on Cloud.

by Adalberto Medeiros at September 29, 2014 06:42 PM

Ben Nemec

Debugging Syntax and Import Errors in OpenStack Unit Tests

Most OpenStack projects use a combination of tox, testr, and subunit to run their unit tests. This works fine as long as you don't have any simple errors in your code, such as a typo in an import or a missing closing paren. In those cases testr or subunit may swallow the error and you won't know exactly where it is (I hear this may be fixed in some version of the tools, but the one I'm currently using still has this limitation). To fix this, we need another way to run unit tests that will expose the actual error to us.

There are a number of different ways to do this, but the one I've been using is:

.tox/py27/bin/python -m testtools.run discover tests

What is this magical incantation? Let me explain:

Python invocation: Using the python from the tox venv means it will find all of the dependencies that were automatically installed by tox, so you don't have to install them all on the host system.
Testtools test runner: Run the tests using the simple testtools test runner. This will report the error that we need.
Testtools discover: Indicates that the test runner should look for tests recursively in the module specified next.
Module containing tests: My example would work for most of the Oslo projects because they put their tests in a top-level module named tests (yes, I know, this isn't a particularly good idea, but in practice it hasn't caused any problems and changing all of the projects to fix it would be an unnecessary headache). For other projects, the module might be something like nova.tests.

And there you have it. Now you should get a useful error message for missing imports or syntax errors. Note that using testtools all the time probably isn't a good idea because it's a much more primitive test runner that doesn't do things like run tests in parallel (at least that I can tell), but in some instances simplicity is what we want.

Run with testr:

${PYTHON:-python} -m subunit.run discover -t ./ ./tests --list 
--- import errors ---
tests.unit.test_lockutilsNon-zero exit code (2) from test listing.
error: testr failed (3)

Run with the method described above:

ERROR: unittest.loader.ModuleImportFailure.unit.test_lockutils
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: unit.test_lockutils
Traceback (most recent call last):
  File "/opt/stack/oslo.concurrency/.tox/py27/lib/python2.7/site-packages/testtools/run.py", line 472, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 230, in _get_module_from_name
    __import__(name)
  File "/opt/stack/oslo.concurrency/tests/unit/test_lockutils.py", line 17, in <module>
    import multiprocessin
ImportError: No module named multiprocessin</module>

by bnemec at September 29, 2014 04:17 PM

Adam Young

Multiple Signers

You have a cloud, I have a cloud.

Neither of use are willing to surrender control of our OpenStack deployments, but we need to inter-operate.

We both have Keystone servers. Those servers are the system of record for user authorization through out our respective deployments. We each wish to maintain control of our assignments. How can we make a set of resources that can be shared?  It can’t be done today.  Here is why not, and how to make it possible.

Simple example:  Nova in OpenStack Deployment A (OSDA) creates a VM using an image from Glance in OpenStackDeployment B. Under the rules of policy, the VM and the image must both reside in the same project. However, the endpoints are managed by two different Keystone servers.

At the Keystone to Keystone level, we need to provide a shared view of the project. Since every project is owned by a domain, the correct level of abstraction is for the two Keystone servers to have a common view of the domain.  In our example we create a Domain in OSDA named “SharedDom” and assume it assigns “54321CBE” as the domain id. Keystone for OSDB needs to have an identical domain. Lets loosen the rules on domain creation to allow that: create domain takes both name and accepts “54321CBE” as the domain’s identifier.

Once we have the common domain definition, we can create a project under “SharedDom” in OSDA and, again, put a copy into OSDB.

Let us also assume that the service catalog has been synchronized across the two Keystone images. While you might be tempted to just make each a region in one Keystone server, that surrenders the control of the cloud to the remote Keystone admin, and so will not be organizationally acceptable. So, while we should tag each service catalog as a region, and keep the region names generally unique, they still are managed by distinct peer Keystone servers.

The API call that creates a VM in one endpoint by fetching an image from another accesses both endpoints with a single token. It is impossible to do today. Which keystone is then used to allocate the token? If it is OSDA, then Glance would reject it. if OSDB, Nova would reject it.

For PKI tokens, we can extract the “Signing Data” from the token body and determine which certificate signed it. From the certificate we can determine which Keystone server signed the token. Keystone would then have to provide rules for which Keystone server was allowed to sign for a domain. By default, it would be only the authoritative Keystone server associated with the same deployment. However, Keystone from OSDA would allow Keystone from OSDB to sign for Tokens under “SharedDom” only.

If both keystone servers are using UUID tokens we could arrange for the synchronization of all tokens for the shared domain across keystone instances. Now each endpoint would still authenticate tokens against its own Keystone server. The rules would be the same as far as determining which Keystone could sign for which tokens, it would just be enforced at the Keystone server level. My biggest concern with this approach is that there are synchronization problems; it has a tendency toward race conditions. But it could be made to work as well.

The agreement can be set one direction.  If OSDA  is managing the domain, and OSDB accepts the agreement, then OSDA can sign for tokens for the domain that are used across both deployments endpoints.   Keystone for OSDA must explicitly add a rule that says that Keystone for OSDB can sign for tokens as well.

This setup works  on a gentleman’s agreement genteel understanding that only one of the two Keystone servers  actively manages the domain.  One Keystone server is delegated the responsibility of managing the domain.  The other one performs that delegation, and agrees to stay out of it.  If the shared domain is proving to be too much trouble, either Keystone server can disable the domain without the agreement of the other Keystone server.

As Mick Jagger sang “Hey, you!  Get off of my cloud!”

by Adam Young at September 29, 2014 03:31 PM

Percona

MySQL & OpenStack: How to overcome issues as your dataset grows

MySQL is the database of choice for most OpenStack components (Ceilometer is a notable exception). If you start with a small deployment, it will probably run like a charm. But as soon as the dataset grows, you will suddenly face several challenges. We will write a series of blog posts explaining the issues you may hit and how to overcome them.

Where is MySQL used in OpenStack?

Have a look at the logical diagram of OpenStack below (click the image for a larger view).

 

MySQL & OpenStack: A deployment primer

The diagram is a bit outdated: Neutron appears as Quantum and newer components like Heat are not pictured. But it shows that a database has to be used to store metadata or runtime information. And although many databases are supported, MySQL is the most common choice. Of course MySQL can also be used in instances running inside an OpenStack cloud.

What are the most common issues?

OpenStack_PerconaAs with many applications, when you start small, the database is running well and maintenance operations are fast and easy to perform. But with a dataset that grows, you will find that the following operations are becoming increasingly difficult:

  1. Having good backups: mysqldump is the standard backup tool for small deployments. While backups of instances having 100GB of data is still quite fast, restore is single-threaded and will take hours. You will probably need to use other tools such as Percona XtraBackup, but what are the tradeoffs?
  2. Changing the schema: whenever you have to add an index, change a datatype or add a column, it can trigger a table rebuild which will prevent writes to proceed on the table. While the rebuild is fast when the table has only a few hundreds of MBs of data, ALTER TABLE statements can easily take hours or days for very large tables. Using pt-online-schema-change from Percona Toolkit is a good workaround, but it doesn’t mean that you can blindly run it without any precaution.
  3. Making the database highly available: whenever the database is down, the whole platform is down or runs in a degraded state. So you need to plan for a high availability solution. One option is to use Galera, but that can introduce subtle issues.
  4. Monitoring the health of your database instances: MySQL exposes hundreds of metrics, how do you know which ones to looked at to quickly identify potential issues?

1. and 2. are not likely to be issues for the MySQL instance backing your OpenStack cloud as it will be very small, but they can be big hurdles for guest databases that can grow very large depending on the application.

3. and 4. are highly desirable no matter the size of the database.

Stay tuned for more related posts on MySQL & OpenStack – and feel free to give us your feedback! And remember that if MySQL is showing bad performance in your OpenStack deployment, Percona is here to help. Just give us a call anytime, 24/7. I also invite you and your team to attend the inaugural OpenStack Live 2015 conference, which runs April 13-14, 2015 in Santa Clara, Calif. It runs alongside the Percona Live MySQL Conference and Expo (April 13-16) at the Hyatt Regency Santa Clara and the Santa Clara Convention Center.

The post MySQL & OpenStack: How to overcome issues as your dataset grows appeared first on MySQL Performance Blog.

by Stephane Combaudon at September 29, 2014 01:00 PM

Thierry Carrez

#1 OpenStack contributor: all of us

It's that time of the year again... As we get to the end of our development cycle, some people look at hard contributions numbers and some companies decide to expose questionable metrics to brag about being #1.

This cycle, it's apparently HP's turn. But you can make numbers say anything... It's true that HP is the largest contributor when you consider the integrated release, the incubated projects and the supporting projects altogether, and we are very happy with HP's involvement in OpenStack. But numbers can always tell a different story if you look at them from a slightly different angle. If you only consider commits to the integrated release (the projects that we will end up releasing as "Juno" in a few weeks), then Red Hat is still #1. If you count code reviews on this same integrated release, then Mirantis leads. If you only consider Documentation, then SUSE leads. It's all pretty balanced and healthy.

Rather than celebrating being #1, we should all celebrate the diversity of our community and our contributors. 132 different organizations were involved. 6% of our code contributions come from individuals who are not affiliated with any company or organization. The Universidade Federal de Campina Grande is #25 in commits to OpenStack projects. B1 systems, a small German consulting firm, is #8, mostly through the work of one person.

Every little bit counts. It doesn't matter who is #1, it matters that we all can contribute, and that we all do contribute. It matters that we keep on making sure everyone can easily contribute. That's what's really important, and I wish we all were celebrating that.

by Thierry Carrez at September 29, 2014 01:00 PM

Tesora Corp

Post #3: Replication and Clustering – A Look ahead

Russian_Nesting_Dolls_Matryoshka_Part_4288_Nolinsk.jpgIn previous blog posts (Replication and Clustering Part #1 and Implementation Details) we described the replication feature for Trove, and the implementation in the Client and the Task Manager in detail.

In this post we describe some of the rationale for this implementation and the roadmap for features that provide performance and availability guarantees that are so critical for a database.

It is well recognized that solutions to problems of database performance and availability are closely interconnected. All of these solutions rely on the ability to have multiple copies of data, and to have multiple computers (that may or may not be at the same location) working together to provide the user with access to data. These kinds of solutions broadly depend on techniques like “replication”, “clustering” and “parallel computing”. While these three terms are often used interchangeably, there are subtle differences that are worth highlighting.

Replication is a mechanism whereby data is available in more than one location. In the simplest case of replication, there is a master and a slave. The master and slave are first synchronized and after that, any change to the master is replicated to the slave. The changes may be replicated synchronously or asynchronously. Replication may either guarantee an ordering of change replication or not and in some cases change ordering may only be guaranteed at specific thresholds called barriers. Databases provided replication natively (semi-synchronous replication in MySQL) or one could use additional software (like Galera or Tungsten), but one could also consider disk mirroring either in hardware or software as forms of replication.

Clustering is a class of techniques where many computers work collectively, and perform some function or functions. For example, if data is replicated between two locations then it is possible for a database to access each data set and answer queries submitted to it. In such a system, one could have a copy of data in one location and accessed by one database instance and data in a either the same or a different location accessed by a second database instance. Then these two database instances would be considered to be a database cluster. In this example, each database instance is able to completely answer queries against the data. Oracle Real Application Clusters (RAC) is an example of a system of this kind. An application which splits writes and reads between a database master and replication slaves is another example of this kind of system.

Parallel computing is a particular example of cluster computing where multiple computers work together to provide some function or function whereby multiple computers each perform some sub-function. In the context of databases, a common example of parallel computing is a parallel database. Here multiple computers each process a subset of a query based on a subset of the data that they have access to. Sharded databases, or most NoSQL databases (MongoDB, Cassandra for example) are examples of this kind of system.

“Clustering” means something different to different data stores.  Since Trove is designed to support this diversity, its implementation of these features must use some common, basic operations to control these data stores in a consistent way. These operations are “to add a replication slave to a data store”, “to add a computer to a cluster”, “to remove a computer from a cluster”, and so on. The actual implementation of those features could then be performed in a manner that was applicable to that particular data store.

Therefore, in replication (v1) we create the framework for this feature and provide an implementation of this framework for MySQL. This implementation includes the feature set related to replicas for MySQL. For this implementation, we use the snapshot and replicate paradigm that is the standard for MySQL systems.

In a subsequent phase the community will deliver clustering which will implement primitives like “create cluster”, “add instance to cluster”, “replace instance” and “remove instance”. This scheme therefore makes it possible for us to also add extensions to these API calls that will define specialized instances for specific data stores such as the “create arbiter” call that will make sense only to MongoDB, which uses the mechanism of an arbiter.

The initial implementations of the replication and clustering feature are currently planned for release in the Juno release. Code for both of these features is under development and expected to be delivered in the juno-2 code drop. Blueprints for these features are currently available on Launchpad.

With the delivery of these features, the Trove project will have a solid framework on which one can implement replication and clustering for an arbitrary data store. We anticipate that with this framework, we (Tesora) will also be able to deliver the capability of a fully parallel MySQL database utilizing the clustering feature for parallelism and replication for redundancy. For this we plan to use the open source Database Virtualization Engine (DVE) capability that we have developed.

In parallel we at Tesora, and other members of the Trove project community (from companies like Mirantis, HP, Rackspace and EBay) are contributing code that will support additional data stores and additional configuration capabilities in those data stores.

While Trove is already in production in a number of enterprises and public clouds, having these capabilities built in will make it dramatically easier to deliver a production-ready, enterprise-grade Database as a Service offering based on Trove in an OpenStack cloud. 

Learn more about Tesora's DBaaS Platform or download a free trial of the Enterprise Edition

 

by 10 at September 29, 2014 12:28 PM

David Moreau Simard

Finding the right Openstack provider

How to find a great Openstack provider. Isn’t that a good question ?

The Openstack foundation thinks so, too. That’s why it announced the release of the Openstack Marketplace at the last Openstack summit in Atlanta.

It’s definitely a step in the right direction towards helping users find trustworthy providers of Openstack services. To be listed, providers must meet basic requirements that are verified by the foundation.

The great thing is that the marketplace is not limited to public or private cloud offerings, you’ll also be able to find offers for training or consulting, too.

Let’s look at some of the most important caracteristics which makes up for a great cloud provider.

The right provider

Using the Marketplace, you’ll be able to search based on some critera - some of which are required to be even considered in my book.

Up-to-date is better

The marketplace tracks the versions of the providers’ deployments. Make sure they’re up-to-date:

Openstack Marketplace Map

Right now, the latest release of Openstack is “Icehouse”.

The next version, “Juno”, is scheduled to be released in mid October 2014.

Newer releases not only fixes bugs but also introduces new features, performance improvements and better integration. You don’t want to get stuck with a provider that isn’t able to or won’t update it’s platform.

Available projects

This one is easy but you need to make sure the provider offers what you need before signing up !

Openstack Marketplace Projects

A typical Openstack deployment should provide, at the very least, the following services:

  • Identity (Keystone): To authenticate with the various Openstack services
  • Compute (Nova): To spawn virtual machines
  • Networking (Neutron): To provide networking to your VMs
  • Images (Glance): To provide OS installation images for your VMs

Then, these will also prove useful but are not necessarily offered by all providers:

  • Block Storage (Cinder): For persistant block volume storage
  • Object Storage (Swift): For object storage
  • Orchestration (Heat): For orchestrating and scaling applications
  • Telemetry (Ceilometer): For metering, billing, used also with Heat
  • Dashboard (Horizon): A web interface for managing most Openstack projects

Location, location, location…

You want your provider to have deployments that are geographically close to your target market. This is more important in some business than others but the less latency, the faster, the better.. right ?

The marketplace makes this one easy by listing each of the location served by each provider.

Openstack Marketplace Location

Openstack Marketplace Map

API Availability

To really leverage the strengths of a flexible cloud deployment, you’ll want API access.

A very common use case with Openstack clouds is that you are able to dynamically spin up and down virtual instances on demand with the help of the API.

Again, the marketplace comes through for us and lists not only the available APIs but also their version and if there are any limitations:

Openstack Marketplace Map

If the complete API is not available, the gauge won’t be full.

Make sure to contact the provider to inquire about possible limitations so you know what to expect. Sometimes, implementations or security will require providers to limit availability to some calls.

The other criterias

By making sure that you’ve got the basics down with the help of the Openstack marketplace, you’ll be in a great position to narrow down the list of providers that look interesting.

Once you have that list, it’ll be time to ask them about the other important things such as price, service level agreements or performance.

Still lost ?

Have questions ? Still lost ?

Drop me a line and we can chat about your requirements.

by dmsimard at September 29, 2014 02:00 AM

September 28, 2014

Sébastien Han

CephDays Paris slides

My slides from the CephDays in Paris. Main topics were:

  • Status of Ceph in OpenStack (Juno cycle)
  • Deploy Ceph with Ansible

<iframe allowfullscreen="true" frameborder="0" height="569" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/1GfvgHeYeonUnCMwYsyx93sjJh0ydsTIJie7SHA5srpk/embed?start=false&amp;loop=false&amp;delayms=3000" webkitallowfullscreen="true" width="960"></iframe>

September 28, 2014 09:13 PM

September 27, 2014

Loïc Dachary

OpenStack Upstream Training challenges

The OpenStack Upstream Training scheduled november 1st, 2014 in Paris will have a unprecedented number of participants and for the first time there is a shortage of Lego. In addition to the 80 pounds of spare parts (picture fourground), six new buildings have been acquired today (Tower Bridge, Sydney Opera, Parisian Restaurant, Pets Shop, Palace Cinema and Grand Emporium). They will be at Lawomatic for assembly form October 1st to October 31st. Anyone willing to participate please send me an email.

Once this first challenge is complete, the buildings will have to be transported to the Hyatt conference rooms where the training will take place. The rendez-vous point is 8am Lawomatic Saturday November 1st, 2014. Each of us will carefully transport a building (or part of it in the case of the Tower Bridge) in the subway. There will be coffee and croissants upon arrival :-)

by Loic Dachary at September 27, 2014 02:58 PM

Lars Kellogg-Stedman

Integrating custom code with Nova using hooks

Would you like to run some custom Python code when Nova creates and destroys virtual instances on your compute hosts? This is possible using Nova's support for hooks, but the existing documentation is somewhat short on examples, so I've spent some time trying to get things working.

The demo_nova_hooks repository contains a working example of the techniques discussed in this article.

What's a hook?

A Nova "hook" is a mechanism that allows you to attach a class of your own design to a particular function or method call in Nova. Your class should define a pre method (that will be called before the method is called) and post function (that will be called after the method is called):

class YourHookClass(object):

    def pre(self, *args, **kwargs):
        ....

    def post(self, rv, *args, **kwargs):
        ....

The pre method will be called with the positional and keyword arguments being passed to the hooked function. The post method receives the return value of the called method in addition to the positional and keyword arguments.

You connect your code to available hooks using Setuptools entry points. For example, assuming that the above code lived in module named your_package.hooks, you might have the following in the corresponding setup.py file:

entry_points = {
    'nova.hooks': [
      'create_instance=your_package.hooks:YourHookClass',
    ]
},

What hooks are available?

The Nova code (as of 81b1bab) defines three hooks:

  • create_instance
  • delete_instances
  • instance_network_info

create_instance

The create_instance hook is attached to the Nova API create function, and will receive the following arguments:

def create(self, context, instance_type,
           image_href, kernel_id=None, ramdisk_id=None,
           min_count=None, max_count=None,
           display_name=None, display_description=None,
           key_name=None, key_data=None, security_group=None,
           availability_zone=None, user_data=None, metadata=None,
           injected_files=None, admin_password=None,
           block_device_mapping=None, access_ip_v4=None,
           access_ip_v6=None, requested_networks=None, config_drive=None,
           auto_disk_config=None, scheduler_hints=None, legacy_bdm=True,
           shutdown_terminate=False, check_server_group_quota=False):

When called, self is a nova.compute.api.API object, context is a nova.context.RequestContext object, instance_type is a dictionary containing information about the selected flavor, and image_href is an image UUID.

During my testing, the instance_type dictionary looked like this...

{'created_at': None,
 'deleted': 0L,
 'deleted_at': None,
 'disabled': False,
 'ephemeral_gb': 0L,
 'extra_specs': {},
 'flavorid': u'2',
 'id': 5L,
 'is_public': True,
 'memory_mb': 2048L,
 'name': u'm1.small',
 'root_gb': 20L,
 'rxtx_factor': 1.0,
 'swap': 0L,
 'updated_at': None,
 'vcpu_weight': None,
 'vcpus': 1L}

...corresponding to the m1.small flavor on my system.

delete_instance

The delete_instance hook is attached to the _delete_instance method in the nova.compute.manager.ComputeManager class, which is called whenever Nova needs to delete an instance. The hook will receive the following arguments:

def _delete_instance(self, context, instance, bdms, quotas):

Where:

  • self is a nova.compute.manager.ComputeManager object,
  • context is a nova.context.RequestContext,
  • instance is a nova.objects.instance.Instance object
  • bdms is a nova.objects.block_device.BlockDeviceMappingList object, and
  • quotas is a nova.objects.quotas.Quotas object

instance_network_info

The instance_network_info hook is attached to the update_instance_cache_with_nw_info function in nova.network.base_api.py. The hook will receive the following arguments:

def update_instance_cache_with_nw_info(impl, context, instance,
                                       nw_info=None, update_cells=True):

I am not running Nova Network in my environment, so I have not examined this hook in any additional detail.

A working example

The demo_nova_hooks repository implements simple logging-only implementations of create_instance and delete_instance hooks. You can install this code, restart Nova services, boot an instances, and verify that the code has executed by looking at the logs generated in /var/log/nova.

by Lars Kellogg-Stedman at September 27, 2014 04:00 AM

September 26, 2014

Red Hat Stack

OpenStack Summit Paris: Agenda Confirms 22 Red Hat Sessions

As this Fall’s OpenStack Summit in Paris approaches, the Foundation has posted the session agenda, outlining the schedule of events. With an astonishing 1,100+ sessions submitted for review, I was happy to see that Red Hat and eNovance have a combined 22 sessions that are included in the weeks agenda, with two more as alternates.

As I’ve mentioned in the past, I really respect the way the Foundation goes about setting the agenda – essentially deferring to the attendees and participants themselves, via a vote. Through this voting process, the subjects that are “top-of-mind” and of most interest in learning more about are brought to the surface, resulting in a very current and cutting edge set of discussions. And with so many accepted sessions, it again confirms that Red Hat, and now eNovance, are involved in some of the most current projects and technologies that the community is most interested in.

As one of the four headline sponsors this year, Red Hat will be participating in the keynote, as well as independent sessions. To learn more about Red Hat’s accepted sessions, have a look at the details below. We look forward to seeing you in Paris!

Red Hat and eNovance OpenStack Summit sessions:

Ask the Experts: Challenges for OpenStack Storage
Here’s your chance! This all-star panel discussion will focus on the challenges for OpenStack storage while responding directly to feedback from users and developers in the audience of their challenges with OpenStack storage…

Monday 3rd 11:40-12:20pm

Neil Levine, Director of Product Management, Red Hat

EMC, NetApp, Hitachi, and SolidFire panelist

Extending Barbican – Managing Secrets and Events Your Way
Barbican provides a simple OpenStack-friendly REST service for secrets management. But what goes on behind the scenes when you make that service call? Barbican can work with many existing technologies and systems to securely store and generate secrets via a plugin approach…

Monday 3rd 11:40-12:20pm

Ade Lee, Principal Software Engineer, Red Hat

Nathan Reller, Chief Engineer, John Hopkins University

John Wood, Software Developer, Rackspace

The Open NFV Organization, Neutron, and OpenDaylight
A new organization has been formed called Open Network Function Virtualization (OP-NFV) under the Linux Foundation. This new organization seeks to create integration projects that combine upstream code from projects such as OpenStack, OpenDaylight and the Linux Kernel, and combine them with extensive testing, custom configuration and possibly upstream code patches…

Monday 3rd 12:30-1:10pm

Chris Wright, Technical Director of SDN, Red Hat

Thomas Nadeau, Engineer, Brocade

Heat Beyond the Basics

In this talk, two of the core developers of Heat will describe the powerful modeling capabilities of the HOT DSL and show you how combine them to deploy and maintain complex applications…

Monday 3rd 12:30-1:10pm

Steven Hardy, Sr Software Engineer, Red Hat

Zane Bitter

Evaluating Vendors and Drivers in OpenStack Deployments with Rally OSProfiler
Everyone is excited about OpenStack these days, and while there’s plenty of flavors of OpenStack for your datacenter, there is limited data for making decisions on the technology stack that runs OpenStack…

Monday 3rd 2:30-3:10pm

Rohan Kanade, Sr Software Engineer, Red Hat

Boris Pavlovic, Technical Lead, Mirantis

When Disaster Strikes the Cloud: The Who, What, When, Where, and How of OpenStack Disaster Recovery
Enterprise applications need to be able to survive large scale disasters. While some born-on-the-cloud applications have built-in disaster recovery functionality, non-born-on-the-cloud enterprise applications typically expect the infrastructure to provide disaster recovery support. OpenStack provides various building blocks that enable an OpenStack application to survive a disaster; these building blocks are being improved in Juno and Kilo…

Monday 3rd 3:20-4pm

Sean Cohen, Principal Product Manager, Red Hat

Michael Factor, Distinguished Engineer, IBM

Ronen Kat, Manager Cloud Storage, IBM Research

OpenStack on a Silver Platter
Over the last months, we could see more and more OpenStack deployments running in production. Installing an OpenStack cloud that can scale does not only mean setting up packages and run your favorite automation tool to configure all the projects together…

Monday 3rd 3:20-4pm

Frederic Lepied, VP Software Engineering, eNovance

Emilien Macchi, Software Engineer, eNovance

Open Source OpenStack Provisioning Tools: What, Why, and How (Panel)

Setting up an OpenStack cloud in the production environment is not an easy task, but there are a number of open source projects to solve the OpenStack deployment problem, including Open Crowbar, Fuel, Compass, Forman, TripleO, etc. Why not just one project? Come listen to the developers who started these projects explain why they chose to build their tools, why they chose to make them open source, what their experience has been with production deployments, what the feedback has been from their users, and what lessons they have learned….

Monday 3rd 4:20-5pm

Keith Basil, Principal Product Manager, Red Hat

and other panelists

Ask the Experts: OpenStack-as-a-Service or as a Distribution (Panel)
This all-star panel discussion will focus on the merits and challenges of deploying OpenStack as either a distribution or as a service.

Monday 3rd 5:10-5:50pm

Jan Mark Holzer, CTO Office, Red Hat

and other panelists

Developing OpenStack as a Framework for NFV
Communication service providers embracing Network Function Virtualization (NFV) are endorsing OpenStack as providing the common API Service Framework required to deliver their applications and services with a lower time to market. This desire for agility is in turn driving increasing pressure for OpenStack to meet the performance, reliability, and determinism requirements of this sector…

Monday 3rd 5:10-5:50pm

Steve Gordon, Sr. Technical Product Manager, Red Hat

Adrian Hoban, Software Architect, Intel

Alan Kavanagh, Expert Cloud Systems Architect, Ericsson

Using OpenStack Swift for Extreme Data Durability
OpenStack Swift is a very powerful object storage that is used in several of the largest object storage deployments around the globe. During this talk we want to give you an overview about the mechanism that are used within Swift to ensure data durability and availability…

Monday 3rd 5:10-5:50pm

Christian Schwede, eNovance

Florent Flament, CloudWatt

Deploying and Auto Scaling Applications on OpenShift with Heat
This session’s goal is to illustrate how DevOps can use Heat to orchestrate the deployment and scaling of complex applications on top of OpenStack. In this example, we’ll use the example of deploying OpenShift Origin (a PaaS) with multiple Brokers & Nodes, MongoDB, DNS requirements – all of which can easily be deployed and managed using Heat….

Tuesday 4th 11:15-11:55am

Diane Mueller, OpenShift Origin Community Mgr, Red Hat

Daneyon Hansen, Software Engineer, Cisco

Authors of the OpenStack Design Guide (Panel)
In July, 2014 The OpenStack Foundation brought twelve members of the OpenStack community together at VMware HQ in Palo Alto, California to produce the OpenStack Design Guide in just 5 days. This panel brings many of these authors together for an open discussion about how to architecture an OpenStack cloud…

Tuesday 4th 2-2:40pm

Steve Gordon, Sr. Technical Product Manager, Red Hat

Vinny Valdez, Principal OpenStack Enterprise Architect, Red Hat

and other panelists from Verizon, Comcast, EMC, Rackspace, VMware, Cisco, and CloudScaling

Neutron Network Node High Availability

Today, you can configure multiple network nodes to host DHCP and L3 agents. In the Icehouse release, load sharing is accomplished by scheduling virtual routers on L3 agents. However, if a network node or L3 agent goes down, all routers scheduled on that node will go down and connectivity will be lost. The Juno release will introduce L3 high availability as well as distributed routing…

Tuesday 4th 2:50-3:10pm

Assaf Muller, Software Engineer, Red Hat

Sylvain, Afchain, Software Engineer, eNovance

Transforming to OpenStack? A Roadmap to Work as a Service

Last summit I had the pleasure to present a talk which encountered some success. Are enterprises ready for the OpenStack transformation? This talk is a follow up on what are the best practices that are successful in operating the transformation…

Tuesday 4th 3:40-4:20pm

Nick Barcet, VP Products, eNovance

Leveraging Existing Identity Sources for OpenStack Clouds
Keystone is the reference implementation of the Identity API in OpenStack. It needs to deal with traditional identity concepts such as users and groups as well as centrally managing authorization. This session will cover how Keystone can leverage existing identity sources for authentication and identity information…

Wednesday 5th 9-9:40am

Nathan Kinder, Software Engineering Manager, Red Hat

Neutron Roundtable: Overlay or Full SDN?

Neutron offers multiple ways to implement networking. It’s not only a matter of vendor choice, but also a choice of networking models. Should the tenants of your cloud be allowed to place requests that would directly modify the configuration of your hardware, or would you like them confined in virtual land? What are the limits of each models and can they be combined? Why would you need access to BGP/OSPF layers from Neutron…

Wednesday 5th 9:50-10:30am

Nick Barcet, VP Products, eNovance

Docker: All the OpenStack Services
Managing the lifecycle of OpenStack’s services is no easy task. In this session users will learn about the lifecycle management challenges faced by enterprises deploying OpenStack including upgrading OpenStack’s services, rolling back services, maintaining service isolation, maximizing use of resources by consolidating services…

Wednesday 5th 9:50-10:30am

James Labocki, Product Manager, Red Hat

Todd Sanders, Director Software Engineering, Red Hat

Rethinking Ceilometer Metric Storage with Gnocchi Time-Series as a Service

When we started Ceilometer, we designed our metrics storage in a way that looked more like audit system that traditional metering tool. Recent evolution in OpenStack and Ceilometer pushed us to rethink how we should treat and store metrics…

Wednesday 5th 11-11:40am

Eoghan Glynn, Principal Engineer, Red Hat

Julien Danjou, Sr Software Engineer, eNovance

Dina Belova, Software Engineer, Mirantis

OpenDaylight and OpenStack Developers (Panel)
OpenStack and OpenDaylight are two open source projects with a lot in common, including the same developers who work on both simultaneously. What makes these projects work so well together and how can you get involved? Ask the developers themselves in this panel discussing policy and control — the point of intersection for the two projects — and the pros and cons of uniting OpenStack’s cloud with OpenDaylight’s controller…

Wednesday 5th 11:50-12:30pm

Chris Wright, CTO Office, Red Hat

and other panelists

Not Invented Here is not an Option”: The Importance of Cross-Community Collaboration
No open source project is built without incorporating the work of others. Even the smallest seemly insignificant python library can play a crucial role in the success or failure your project, even the choice of languages you use to implement your project can have a huge impact. No one can afford to build in isolation…

Wednesday 5th 1:50-2:30pm

Diane Meuller, OpenShift Origin Community Mgr, Red Hat

Taking the Long View: How the Oslo Program Reduces Technical Debt
In the fast-paced world of OpenStack development, we often focus on short-term needs like bug fixes and new features. The Oslo Program takes a longer view of the health and sustainability of the project. Our mission is to make OpenStack more maintainable by addressing cross-project code reuse and architectural issues. In this presentation we will cover the origins of Oslo and the processes and tools the team uses to improve OpenStack from the bottom up…

Wednesday 5th 5:20-6pm

Mark McLoughlin, Consulting Engineering Mgr, Red Hat

Doug Hellmann, Oslo PTL, HP

by jeffja at September 26, 2014 10:39 PM

OpenStack Blog

OpenStack Community Weekly Newsletter (Sep 19 – 26)

How is your OpenStack team organized?

I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research. Fill in this brief survey or contact Stefano Maffulli directly via email (replying to this message).

Journey of IPv6 in OpenStack

With the exhaustion of IPv4 addresses, IPv6 is no longer a choice but is now a necessity, even more so in case of a cloud environment. Sridhar Gaddamat shares his notes on how IPv6 support has evolved in OpenStack with references at appropriate places to where you will be able to find more information.

Deploying Humanitarian Applications On OpenStack At Grace Hopper Open Source Day

This year, Iccha Sethi, Egle Sigler and Dana Bauer, along with other Rackers and OpenStackers, will lead a workshop for developers on how to deploy humanitarian applications on OpenStack during the Grace Hopper Celebration of Women in Computing.

Reports from Previous Events

The Road To Paris 2014 – Deadlines and Resources

During the Paris Summit there will be a working session for the Women of OpenStack to frame up more defined goals and line out a blueprint for the group moving forward. We encourage all women in the community to complete this very short survey to provide input for the group.

Relevant Conversations

Tips ‘n Tricks

Security Advisories and Notices

Upcoming Events

Other News

Got Answers?

Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:

Welcome New Reviewers, Developers and Core Reviewers

Vinny Valdez Ionut-Madalin Balutoiu
Steven Ren Victor Silva
Kamil Rykowski Dustin Schoenbrun
Victor Silva Noel Burton-Krahn
Tetiana Lashchova JC Smith
Lena Novokshonova Tony Breeds
jazeltq Rushil Chugh
Rafael Rivero Shivanand Tendulker
Ian Govett Kamil Rykowski
Johan Viklund
Denise Hale

OpenStack Reactions

haters-to-the-left

When I see a long and very much animated email thread starting on openstack-devel

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.

by Stefano Maffulli at September 26, 2014 08:29 PM

Jay Pipes

Answering the existential question in OpenStack

There have been a slew of threads on the OpenStack Developer mailing list in the last few months that touch on overall governance and community issues. Thierry Carrez’s “the future of the integrated release” thread sparked discussions around how we keep up with the ever-increasing number of projects in the OpenStack ecosystem while maintaining quality and stability. Discussions around where to place the Rally program, suggestions of creating a Neutron Incubator program, and the debate around graduating Zaqar from incubation all bring up fundamental questions about how the OpenStack community is going to cope with the incredible growth it is experiencing.

Underneath these discussions, however, is an even more pivotal question that remains to be answered. Chris Dent put it well in his recent response on the Zaqar thread:

http://bit.ly/big-top-tent

http://bit.ly/big-top-tent

Which leads inevitably to the existential questions of What is OpenStack in the business of? and How do we stay sane while being in that business?

I have a few thoughts on these questions. A definitive opinion, if you will. Please permit me to wax philosophical for a bit. To be fair, my thoughts on this topic have changed pretty dramatically over the last few years, and as my role in the OpenStack world has evolved from developer to operator/deployer to developer again, from being on the Project Policy Board (remember that?), to being on the Technical Committee, off the TC, and then on it again.

What is OpenStack in the business of?

I believe OpenStack is in the business of providing an extensible cloud platform built on open standards and collaboration.

In other words, we should be a Big Tent. Our policies and our governing structure should all work to support people that collaborate with each other to enhance the experience of users of this extensible cloud platform.

What would being a Big Tent mean for the OpenStack community?

To me, being a Big Tent means welcoming projects and communities that wish to:

  • “speak” the OpenStack APIs
  • extend OpenStack’s reach, breadth, and interplay with other cloud systems
  • enhance the OpenStack user experience

Note that I am deliberately using the generic term “user” in the last bullet point above. Users include application developers writing against one or more public OpenStack APIs, developers of the OpenStack projects, deployers of OpenStack, operators of OpenStack, and anyone else who interfaces with OpenStack in any way.

What would being under the OpenStack tent mean for a project?

What would “being under the tent” mean for a project and its community? I think there’s a pretty simple answer to this as well.

A project included in the OpenStack Big Tent would mean that:

  1. The project is recognized as being a piece of code that enhances the experience of OpenStack users
  2. The project’s source code lives in the openstack/ code namespace

Clearly, I’m talking here only about projects that wish to be included in the OpenStack tent here. I’m not suggesting that the OpenStack community go out and start annexing parts of other communities and bringing their source code into the OpenStack tent willy-nilly!

…and what would being under the tent not mean for a project?

Likewise, being under the OpenStack Big Tent should not mean any of the following:

  • That the project is the only way to provide a specific function to OpenStack users
  • That the project is the best way to provide a specific function to OpenStack users
  • That the project receives some allotted portion of shared technical or management resources

Note that the first two bullet points above go towards my opinion that the OpenStack community should embrace competition both within its ecosystem as well as embrace competition in the external community by identifying ways to increase interoperability. Specifically, I don’t have a problem with having projects under the OpenStack tent that share some common functionality or purpose.

What requirements must projects meet?

Finally, there is the question of what requirements a project that wishes to be under the OpenStack tent must meet? I think minimal is better here, as it lowers the barriers to entry for interested parties. I think the below items keep the bar high enough to ensure that applicants aren’t just trying to self-promote without contributing to the common good of OpenStack.

  • Source code is licensed under the Apache License or a compatible FLOSS license and code is submitted according to a Developer Certificate of Origin
  • There should be liaisons for release management and cross-project coordination
  • There should be documentation that clearly describes the function of the project, its intended audience, any public API it exposes, and how contribution to the project is handled

And that’s it. There would be no further requirements for a project to exist under the OpenStack tent.

Predicting a few questions

I’m going to go out on a limb and try to predict some questions that might be thrown my way about my answer to the existential question of OpenStack. Not only do I believe this is a good exercise for anyone who plans to defend their thoughts in the court of public opinion, but I think that having concrete answers to these questions will help some folks recognize how this change in overall OpenStack direction would affect specific decisions and policies that have come to light in recent months.

What about the gate? How will the gate possibly keep up with all these projects?

The gate is the test platform that guards the branches of the OpenStack projects that are in the Integrated OpenStack release against bugs that result from merging flawed code in a dependent project. This test platform consists of hundreds of virtual machines that run a set of integration tests against OpenStack environments created using the Devstack tool.

http://bit.ly/pug-on-gate

http://bit.ly/pug-on-gate

The gate is also composed of a group of talented humans who each have demonstrated heroic characteristics in the past four years during periods in which the gate or its underlying components get “wedged” and needs to be “unstuck.”

These talented engineers, known collectively as the OpenStack Infra team, are a resource that is shared among projects in the OpenStack community. Currently, in the OpenStack community means the set of code that lives in the openstack/ namespace AND the stackforge namespace. However, while the OpenStack Infra team is shared among all projects in the OpenStack community, the gate platform is NOT shared by all projects in the community. Instead, the gate platform (the integrated queue) is only available to the projects in the OpenStack community that are in the incubated and integrated project statuses.

Now, it is 100% true that given the current structure of our gate test platform, for each additional project that is included in the current OpenStack Integrated Release, there is an exponential impact on the number of test machines and the amount of test code that will be run in the gate platform. I will be the first to admit that.

However, I believe the gate test platform does not need to impose this limitation on our development and test processes. I believe the gate, in its current form, produces the kind of frustration that it does because of the following reasons:

  • We don’t use fail-fast policies in the gate
  • We don’t use hierarchical test construction properly in the gate
  • We assume bi-directional test dependence when all dependencies are uni-directional
  • We run tests against code that a patch does not touch
  • We only have one gate
  • Expectations of developers trying to merge code into a tree are improperly set

By rethinking what the gate test platform is doing, and especially rethinking the policies that the gate enforces, I think we can test more projects, more effectively. I’m not going to go into minute detail for each of the above items, as I will do that in a followup post. The point here is to step back a bit and see if the policies we’ve given ourselves might just be the cause of our woes, and not the solution we think they might be.

Would there continue to be an incubation process or status?

Short answer: No.

http://bit.ly/incubate-my-chicken

http://bit.ly/incubate-my-chicken

The status of incubation within OpenStack has become the end goal for many projects over the last 3 years. The reason? Like it or not, the reason is because being incubated means the project gets to live in the openstack/ code namespace. And being in the openstack/ code namespace brings an air of official-ness to a project. It’s not rational, and it’s not sensible, but the reality is that many companies will simply not dedicate resources (money and people, which cost money) to the development of a project that does not live in the openstack/ code namespace. If our goal, as a community, is to increase the adoption of projects that enhance the user experience of OpenStack, then the incubation status, and the barrier to inclusion that comes with it, is not helping that goal.

The original aims of the incubation process and status were to push projects that wished to be called “OpenStack” to adopt a consistent release cadence, development workflow and code review system. It was assumed that by aligning these things with other projects under the OpenStack tent, that these projects would become better integrated with each other, by nature of being under the same communal constraints and having to coordinate their development through a shared release manager. These are laudable goals, but in practice, incubation has become more of a status symbol and political campaign process than something that leads to increased integration with other OpenStack projects.

Do we still want to encourage projects that live under the OpenStack tent to work with each other where appropriate? Absolutely yes. However, I don’t think the existing incubation process, which features a graduation review (or three, or four) in front of the Technical Committee, is something that is useful to OpenStack users.

Application developers want to work with solid OpenStack APIs and easy-to-use command line and library interfaces. The incubation process doesn’t address these things specifically.

Deployers of an OpenStack cloud platform want to deploy various OpenStack projects using packages or source repositories (and sometimes both). The process of incubation doesn’t address the stability or cohesiveness of operating system packages for the OpenStack project. This is something that would be better handled with a working group comprised of folks from the OpenStack and operating system distributions, not by a graduation review before the Technical Committee.

Operators of OpenStack cloud platforms want the ability to easily operate, maintain, and upgrade the OpenStack projects that they choose to utilize. Much of the operator tooling and utilities live outside of the openstack/ code namespace, either in the stackforge/ code namespace or in random repositories on GitHub. By not having OpenStack-specific operator tooling in the openstack/ code namespace, we de-legitimize these tools and make the business decision to use them harder. The incubation process, along with the Technical Committee “come before the court” bottleneck, doesn’t enable these worthy tools and utilities to be used as effectively as they could be, which ultimately means less value for our operator users.

Won’t the quality of OpenStack suffer if we let too many projects in?

No, I don’t believe it will. Or at least, I don’t believe that the quality of OpenStack as a whole is a function of how many projects we let live in the openstack/ code namespace. The quality of OpenStack projects should be judged separately, not as a whole. It’s neither fair to older, mature projects to group them with newcomers, noris it reasonable to hold new projects to the standards of stability and quality that 5+ year old software has evolved to.

I think instead of having an OpenStack Integrated Release, we should instead have tags that describe the stability and quality of a particular OpenStack project, along with much more granular integration information.

In other words, as a deployer, I couldn’t care less whether Ceilometer is “in the integrated release.”

What I do care about, however, is whether the package of Neutron I’m installing emits notifications in a format that the package of Ceilometer I’m installing understands and tracks.

As a deployer, I don’t care at all that Swift is “in the integrated release.”

What I do care about is whether my installed Glance package is able to store images in and stream images from a Swift deployment I installed last May.

As a cloud user, I don’t care at all that Nova is “in the integrated release.”

What I do care about is whether the version of Nova installed at my cloud provider will work with the version of python-novaclient I happened to install on my laptop.

So, instead of going through the arduous and less-than-useful process of graduation and incubation, I would prefer we spend our limited resources working on very specific documentation that clearly tells OpenStack users about the tested integration points between our OpenStack client, server and library/dependency projects.

Would MarconiZaqar be in the integrated OpenStack release under this scheme?

No. I don’t believe we need an integrated release. Yes, Zaqar would be under the OpenStack tent, but no, there would be no integrated release.

Would Stacktach, Monasca and Ceilometer both live in the openstack/ code namespace?

If that is something the Stacktack and Monasca communities would like, and once they meets the requirements for inclusion under the OpenStack tent, then yes. And I think that’s perfectly fine. Having Stacktach under the same tent does not mean Ceilometer isn’t a viable option for OpenStack users. Nor does it mean that Stacktach is the best solution in the telemetry space for OpenStack users.

Our decisions should be based on what is best for our OpenStack users. And I think giving our users choices in the telemetry space is what is best for our users. What works for one user may not be the best choice for another user. But, if we focus on the documentation of our projects in the OpenStack tent (see the requirements for projects to be under the tent, above), we can let these competing visions co-exist peacefully while having our user’s best interests in our hearts.

Would Stacktach and Ceilometer both be called “OpenStack Telemetry” then?

No. I don’t believe the concept of Programs is useful. I’d like to get rid of them altogether and replace the current programs taxonomy with a looser tag-based system. Monty Taylor, in this blog post, has some good ideas on that particular topic, including using a specific tag for “production readiness”.

Would the Technical Committee still decide which projects are in OpenStack?

No. I believe the Technical Committee should no longer be this weird court before which prospective projects must plead their case for inclusion into OpenStack. The requirements for a project to be included in the OpenStack tent should be objective and finite, and anyone on the new project-config-core team should be able to vet applicants based on the simple list of requirements.

How would this affect whether some commercial entity can call its product OpenStack?

This would not affect trademark, copyright, or branding policies in any way. The DefCore effort, of which I have pretty much steered as clear of as possible, is free to concoct whatever legal and foundation policies it sees fit with regards to what combinations of code and implementation can be called “powered by OpenStack”, “runs on OpenStack”, or whatever else business folks think gives them a competitive edge. I’ll follow up on the business/trademark side of OpenStack in a separate post, but I want to make it clear that my proposed broadening of the OpenStack tent has no relation to the business side of OpenStack. This is strictly a community approach.

What would happen to the stackforge/ code namespace?

Nothing. Projects that wished to continue to be in the OpenStack ecosystem but do not meet the requirements for being under the OpenStack tent could still live in the stackforge/ code namespace, same as the they do today.

What benefits does this approach bring?

The benefits of this approach are as follows:

  1. Clarity: due to the simple and objective requirements for inclusion into the OpenStack tent, there will be a clear way to make decisions on what should “be OpenStack”. No more ongoing questions about whether a project is “infrastructure-y enough” or aggravation about projects’ missions or functionality overlapping in certain areas.
  2. Specificity: no more vague reference to an “integrated release” that frankly doesn’t convey the information that OpenStack users are really after. Use quality and integration tags to specify which projects integrate with which versions of other projects, and focus on quality, accurate documentation about integration points instead of the incubated and integrated project status symbols and graduation process.

  3. Remove the issue of finite shared resources from the decision-making process: Being “under the OpenStack tent” does not mean that projects under the tent have any special access to or allocation of shared resources such as the OpenStack infrastructure team. Decisions about whether a project should be “in OpenStack” therefore need not be made based on resource constraints or conditions at a specific point in time. This means fewer decisions that look arbitrary to onlookers.
  4. Convey an inclusive attitude: Clearer, simpler, more objective rules for inclusion into the OpenStack tent means that the OpenStack community will present an inclusive attitude. This is the opposite of our community’s reputation today, which is one where we are viewed as having meritocracy at a micro-level (within the contributor communities in a project), but a hegemony at a macro-level, with a Cabal of insiders judging whether programs meet subjective determinations of what is “cloudy enough” or “OpenStack enough”. The more inclusive we are as a community, the more we will attract the application developers to the OpenStack community, and its on the backs of application developers that OpenStack will live or die in the long run.

Thanks for reading. I look forward to your comments.

by jaypipes at September 26, 2014 06:33 PM

Russell Bryant

PTLs and Project Success in OpenStack

We’re in the middle of another PTL change cycle.  Nominations have occurred over the last week.  We’ve also seen several people step down this cycle (Keystone, TripleO, Cinder, Heat, Glance).  This is becoming a regular thing in OpenStack.  The PTL position for most projects has changed hands over time.  The Heat project changes every cycle.  Nova has its 3rd PTL from a 3rd company (about to enter his 2nd cycle).  With all of this change, some people express some amount of discomfort and concern.

I think the change that we see is quite healthy.  This is our open governance model working well.  We should be thrilled that OpenStack is healthy enough that we don’t rely on any one person to move forward.

I’d like to thank everyone who steps up to fill a PTL position.  It is a huge commitment.  The recognition you get is great, but it’s really hard work.  It’s quite a bit more than just technical leadership.  It also involves project management and community management.  It’s a position subject to a lot of criticism and a lot of the work is thankless.  So, thank you very much to those that are serving as a PTL or have served as one in the past.

It’s quite important that everyone also realize that it takes a lot more than a PTL to make a project successful.  Our project governance and culture includes checks and balances.  There is a Technical Committee (TC) that is responsible for ensuring that OpenStack development overall remains healthy.  Some good examples of TC influence on projects would be the project reviews the TC has been doing over the last cycle, working with projects to apply course corrections (Neutron, Trove, Ceilometer, Horizon, Heat, Glance).  Most importantly, the PTL still must work for consensus of the project’s members (though is empowered to make the final call if necessary).

As a contributor to an OpenStack project, there is quite a bit you can do to help ensure project success beyond just writing code.  Here are some of those things:

Help the PTL

While the PTL is held accountable for the project, they do not have to be responsible for all of the work that needs to get done.  The larger projects have started officially delegating responsibilities.  There is talk about formalizing aspects of this, so take a look at that thread for examples.

If you’re involved in a project, you should work to understand these different aspects of keeping the project running.  See if there’s an area you can help out with.  This stuff is critically important.

If you aspire to be a PTL at some point in the future, I would say getting involved in these areas is the best way you can grow your skills, influence, and visibility in the project to make yourself a strong candidate in the future.

Participate in Project Discussions

The direction of a project is a result of many discussions.  You should be aware of these and participate in them as much as you can.  Watch the openstack-dev mailing list for discussions affecting your project.  It’s quite surprising how many people may be a core reviewer for a project but rarely participate in discussions on the mailing list.

Most projects also have an IRC channel.  Quite a bit of day-to-day discussion happens there.  This can be difficult due to time zones or other commitments.  Just join when you can.  If it’s time zone compatible, you should definitely make it a priority to join weekly project IRC meetings.  This is an important time to discuss current happenings in the project.

Finally, attend and participate in the design summit.  This is the time that projects try to sync up on goals for the cycle.  If you really want to play a role in affecting project direction and ensuring success, it’s important that you attend if possible.  Of course, there are many legitimate reasons some people may not be able to travel and those should be understood and respected by fellow project members.

Also keep in mind that project discussions span more than the project’s technical issues.  There are often project process and structure issues to work out.  Try to raise your awareness of these issues, provide input, and propose new ideas if you have them.  Some good recent examples of contributors doing this would be Daniel Berrange putting forth a detailed proposal to split out the virt drivers from nova, or Joe Gordon and John Garbutt pushing forward on evolving the blueprint handling process.

Do the Dirty Work

Most contributors to OpenStack are contributing on behalf of an employer.  Those employers have customers (which may be internal or external) and those customers have requirements.  It’s understandable that some amount of development time goes toward implementing features or fixing problems that are important to those customers.

It’s also critical that everyone understands that there is a good bit of common work that must get done.  If you want to build goodwill in a project while also helping its success, help in these areas.  Some of those include:

See You in Paris!

I hope this has helped some contributors think of new ways of helping ensuring the success of OpenStack projects.  I hope to see you on the mailing list, IRC, and in Paris!


by russellbryant at September 26, 2014 03:35 PM

OpenStack Board Meeting – 2014-09-18

I’m not a member of the OpenStack board, but the board meetings are open with the exception of the occasional Executive Session for topics that really do need to be private.  I attended the meeting on September 18, 2014.  Jonathan Bryce has since posted a summary of the meeting, but I wanted to share some additional commentary.

Mid-Cycle Meetups

Rob Hirschfeld raised the topic of mid-cycle meetups.  This wasn’t discussed for too long in the meeting.  The specific request was that the foundation staff evaluate what kind of assistance the foundation could and should be providing these events.  So far they are self-organized by teams within the OpenStack project.

These have been increasing in popularity.  The OpenStack wiki lists 12 such events during the Juno development cycle.  Some developers involved in cross project efforts attended several events.  This increase in travel has resulted in some tension in the community, as well.  Some people have legitimate personal reasons for not wanting the additional travel burden.  Others mention the increased impact to company travel budgets.  Overall, the majority opinion is that the events are incredibly productive and useful.

One of the most insightful outcomes of the discussions about meetups has been that the normal design summit is no longer serving its original purpose well enough.  The design summit is supposed to be the time that we sync on project goals.  We need to work on improving the design summit so that it better achieves that goal so that the mid-cycle meetups can be primarily focused on working sessions to execute on the plan from the design summit.

There was a thread on the openstack-dev list discussing improvements we can make to the design summit based on mid-cycle meetup feedback.

Foundation Platinum Membership

Jonathan raised a topic about how the foundation and board should fill a platinum sponsor spot that is opening up soon.  The discussion was primarily about the process the board should use for handling this.

This may actually be quite interesting to watch.  Nebula is stepping down from its platinum sponsor spot.  There is a limit of 8 platinum sponsors.  This is the first time since the foundation launched that a platinum sponsor spot has been opened.  OpenStack has grown an enormous amount since the foundation launched, so it’s reasonable to expect that there will be contention around this spot.

Which companies will apply for the spot?  How will the foundation and board handle contention?  And ultimately, which company will be the new platinum sponsor of the foundation?

DefCore

This topic took up the majority of the board meeting and was quite eventful.  Early in the discussion there was concern about the uncertainty caused by the length of the process so far.  There seemed to be general agreement that this is a real concern.  Naturally, the conversation proceeded to how to move forward.

The goal of DefCore has been around defining a single minimal definition to support the single OpenStack Powered trademark program.  The most important outcome from this discussion was that the board consensus seemed to be that this is causing far too much contention and that the DefCore committee should work with the foundation to propose a small set of trademark programs instead of trying to have a single one that covered all cases.

There were a couple of different angles discussed on creating additional trademark programs.  The first is about functionality.  So far, everything has been included in one program.  There was discussion of separate compute, storage, and networking trademark programs, for example.

Another angle that seemed quite likely based on the discussion was having OpenStack powered vs. OpenStack compatible trademark programs.  An OpenStack compatible program would only focus on compatibility with capabilities.  The OpenStack powered trademarks would include both capabilities and required code (designated sections).  The nice thing about this angle is that it would allow the board to press forward on the compatibility marks in support of the goal of interoperability, without getting held up by the debate around designated sections.

For more information on this, follow the ongoing discussion on the defcore-committee mailing list.

Next Board Meeting

The next OpenStack board meeting will be Nov. 2, 2014 in Paris, just before the OpenStack Summit.  There may also be an additional board meeting to continue the DefCore discussion.  Watch the foundation list for any news on additional meetings.


by russellbryant at September 26, 2014 03:33 PM

Red Hat Stack

Free webinar on the Heat orchestration service

On Tuesday, September 30, we will presenting a Taste of Red Hat Training webinar dedicated to Heat, the Red Hat Enterprise Linux OpenStack Platform orchestration service that allows you to run multiple composite cloud applications. There will be two live sessions of the webinar run that day, at 9 am EST and 2 pm EST to accommodate the usual international audience.

Join Red Hat curriculum developer, Adolfo Vazquez, as he teaches you about the basics of the Heat orchestration service in Red Hat Enterprise Linux OpenStack Platform, the Heat core services, and how to configure applications on the OpenStack infrastructure. Content for the webinar is pulled directly from our popular Red Hat OpenStack Administration (CL210) course.

Click here for more information and to register.

by Maria Gallegos at September 26, 2014 10:52 AM

Opensource.com

OpenStack day two operations tools

Automation is all about maintaining and managing the cloud infrastructure and workload to keep it running. Get to the creative work quicker with these "day two operations tools" for automating in OpenStack.

by Dmitri Zimine at September 26, 2014 09:00 AM

September 25, 2014

Stefano Maffulli

How is your OpenStack team organized?

I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research.

I’m especially interested in learning about internal processes, system of incentives, things that impact performance evaluation for engineers contributing to OpenStack.

To expand the research I’m asking the OpenStack community to fill in this brief survey or contact me directly (stefano openstack.org) for a quick interview.
<iframe frameborder="0" height="500" marginheight="0" marginwidth="0" src="https://docs.google.com/forms/d/15vX9pGlvBVftq4YlD6vE0rOMKq9e3U25Qh_9gJ6Ky_4/viewform?embedded=true" width="600">Loading…</iframe>


© stefano for ][ stefano maffulli, 2014. | Permalink | No comment | Add to del.icio.us
Post tags: , , ,

Feed enhanced by Better Feed from Ozh

by stefano at September 25, 2014 10:19 PM

Mirantis

OpenStack Swift and the hash_path_suffix – what can go wrong?

OpenStack Swift uses hash values to store objects. Hashing uses a mathematical algorithm to transform data, for instance a string, into a numeric representation. If the underlying data changes, the hash changes, so hashing can be used to detect changes in the data.

Swift uses the well-known MD5 hashing algorithm to transform the path of a Swift object into a hash value. A segment of the hash generated from the path to the inbound or requested object is used to specify the partition used to store the object. The complete hash is then used to position the object inside this partition.

In a perfect hash, every possible input string would be represented by a unique hash value, but the hash function used in Swift can not be perfect. The MD5 hash Swift uses is 16 bytes long and represents arbitrary-length strings, so there’s no guarantee that two different strings have different hash representations.

Malicious use of hash collisions

Using non-unique hash values for placing objects bears a risk. It’s possible for two objects with different object paths to translate into the same hash, and thus be stored in the same place in Swift. In that case, the second object stored overwrites the first.

This flaw means that malicious attackers can hand craft an object path whose hash matches the hash of the object path of the object they want to replace with their copy. The object they are inserting — even though it has a totally different object path from the original — would then overwrite the original object. A user retrieving the original object would not be able to tell that it’s been replaced.

Protecting the hash

Early on, the Swift developers realized that this attack vector posed a substantial risk and implemented protection against this form of attack. The hash_path_suffix is defined in the configuration files for swift on each storage node. It must be the same across the whole cluster and, just as importantly, must be kept secret.

To calculate the hash with the hash_path_suffix, the suffix is added to the object path of the requested object, and then the hash is made from the resulting string. Thus, if an attacker tries to insert an object with the same hash as an existing file, the hashes of the strings modified with the hash_path_suffix will not match, because the secret hash_path_suffix is required to create the hash.

This means that without knowing the hash_path_suffix,  it is no longer possible for an external attacker to knowingly create an alternate URI that produces the same hash as the original.

(There is still a tiny risk that the hashes will still match because of the general risk of MD5 collisions. This risk, though, is exceedingly small and does not provide a viable attack vector for the malicious attacker.)

The risk of misconfiguration

Unlike the rings, the hash_path_suffix cannot change over the life of the cluster. New nodes that are added must use the same hash_path_suffix as the pre-existing nodes.

Now what would happen if a node was added with a different hash_path_suffix?

For an explanation we must look at the auditors. Auditors are processes that constantly scour the data space of a Swift cluster, comparing hash values and MD5 sums with the desired values to detect both corruption of copies and objects that are written in the wrong place.

For our consideration, the hash comparison is of interest. The auditor compares the hash of the object path plus the hash_path_suffix with the hash from the location of the object. As the hash_path_suffix on the object is incorrect on our newly added server, the auditor will remove the “broken” copy from its location and store it in a quarantine space.

How to fix what is broken

Once the fault is detected by the cluster operator — usually through log messages — the hash_path_suffix must be corrected and all swift services on the defective node restarted. Once that’s done, internal replication can sync a good copy of the respective objects into their correct positions from another node.

It’s important to note that while this process can even work if multiple hosts have objects quarantined with the incorrect hash_path_suffix, it does require that there’s at least one good copy of the object remaining to be synced once the configuration has been corrected.

If the number of defective storage nodes is equal to or larger than the replication factor, some objects will have all copies quarantined. In this case, Swift can not automatically replace the missing objects, because no good objects are left to replicate.

In this case, you have two options for recovery:

It is possible to reinsert the objects manually into at least one correct location, and then let the normal internal replication sync. This requires a significant amount of calculation to determine the correct positions, and as internal replication is not designed to be fast, will also take a significant amount of time until consistency is reached.

Often it will be easier to extract the objects from the quarantine and upload them again with the original object path. Not only will this transfer the burden of location calculation to the cluster, but it will also quickly write at least a quorum of objects and thus better protect you from losing the object again, for instance due to hardware failure before internal replication can be achieved.

The easiest method, though, is prevention. Scripting the install, or at least copying the configuration files instead of manually editing them, helps eliminate this kind of mishap, and keeps valuable data safe.

Conclusion

The hash_path_suffix mechanism is useful for protecting a Swift cluster from a certain class of malicious attacks, but at the price of additional configuration effort. As with other OpenStack components, automation of installation and configuration significantly reduces the risk misconfiguration. Recovery is possible, but time consuming and prevention should be prioritized.

The post OpenStack Swift and the hash_path_suffix – what can go wrong? appeared first on Mirantis | The #1 Pure Play OpenStack Company.

by Christian Huebner at September 25, 2014 03:42 PM

The Official Rackspace Blog » OpenStack

Industry-Leading Uptime Guarantee, Improved Scalability: Rackspace Private Cloud

Stability and scalability are imperative in an enterprise private cloud. Your workloads demand that your private cloud is up and running and that it can grow with your business.

Since we launched our Rackspace Private Cloud three years ago, our mission has been to give enterprises a scalable and stable OpenStack-powered private cloud designed specifically for their most demanding workloads. And that private cloud needs the flexibility to be deployed anywhere – our data centers or yours.

And today, with new enhancements to Rackspace Private Cloud, we’re taking stability and scalability to the next level. Built on Icehouse, the latest release of OpenStack, the enhanced Rackspace Private Cloud now features industry-leading stability and massive scalability, along with support for DevOps Automation Services.

Our enhanced Rackspace Private Cloud now offers an industry-leading 99.99 percent OpenStack API uptime guarantee to ensure your enterprise production workloads stay up and running – and you’ll get account credits if we fail to meet that promise. And it’s been updated to scale to more than 200 physical nodes and deliver high availability from a four-server control plane. The improved Private Cloud uses Linux containers, which allow you to independently scale each service and perform seamless, in-place upgrades from one version to another.

With this version of Rackspace Private Cloud we now offer DevOps Automation Services to help you automate your process for deploying and scaling applications. Additionally, Rackspace Private Cloud now supports OpenStack Orchestration, known also as Heat, to help you automate the provisioning of infrastructure, services and applications.

Rackspace Private Cloud is backed by our award-winning Fanatical Support, which includes 24×7 access to our cloud experts, proactive monitoring and more, along with the option for a dedicated OpenStack engineer. Rackspace Private Cloud is a key pillar of the Rackspace Managed Cloud, meaning we’ll handle the heavy lifting and management so you can focus on developing revenue-generating applications without the need to invest millions in building an in-house cloud management team.

To help you get the most out of your Rackspace Private Cloud, we have also just released a new Rackspace Private Cloud reference architecture, which comprises a recommended set of software and infrastructure components to ensure your private cloud meets your scalability, stability and high availability needs. Check out the Rackspace Private Cloud reference architecture here.

The enhanced Rackspace Private Cloud is available now to US customers. It will be available to international customers in October 2014.

Learn more about the enhancements to Rackspace Private Cloud during an overview webinar on Thursday, October 2 at 10 a.m. CDT. You can register for the webinar here.

by Darrin Hanson at September 25, 2014 01:00 PM

Angus Salkeld

Deap dive into using Heat Alarms

So this is just some output from me debugging how Heat’s alarms work with the other parts
of OpenStack (warts-n-all).

First some histroy

Way back, Heat needed alarms to be able to do autoscaling (because it is really useful). The only problem
was we didn’t have Ceilometer back then. So we wrote a minimalist version of Cloud Watch, it was not
suposed to last very long as we fully expected some monitoring-aas to come along. Alas, it has lasted a
lot longer then expected. Also note that we didn’t have Alarms based on notifcations at this point so
all metrics were generated by an agent (cfn-push-stats).

Using Cloud Watch alarms

First off how you can choose the implementation (Ceilometer/Heat).

We use the global environment to configure this. Look in /etc/heat/environment.d/default.yaml
Just uncomment the one you want (We HIGHLY recommend Ceilometer).

resource_registry:
# Choose your implementation of AWS::CloudWatch::Alarm
"AWS::CloudWatch::Alarm": "file:///etc/heat/templates/AWS_CloudWatch_Alarm.yaml"
#"AWS::CloudWatch::Alarm": "OS::Heat::CWLiteAlarm"

Note: the default will change this cycle to use Ceilometer for Cloud Watch Alarms.

There are unfortunately some differences depending on the implementation and whether or not
you are using cfn-push-stats.

A note about cfn-push-stats “–watch”
Basically this was a mistake in implementation as it causes a circular dependancy (this was hidden at
the time of implementation as way back then Ref returned only the resource name, not a resource instance.
(AWS does not do this, they use tags, like we now do)
Basically you should just drop the “–watch” option (it’s just not needed anymore).

Some Cloud Watch examples

CWLiteAlarm with in guest agent

https://github.com/asalkeld/autoscaling-testing/tree/master/AWS_CW_cfn_push_stats_with_watch

https://github.com/asalkeld/autoscaling-testing/tree/master/AWS_CW_cfn_push_stats

AWS_CloudWatch_Alarm.yaml with built in Ceilometer metrics

https://github.com/asalkeld/autoscaling-testing/tree/master/AWS_CW

AWS_CloudWatch_Alarm.yaml with in guest agent

https://github.com/asalkeld/autoscaling-testing/tree/master/AWS_CW_cfn_push_stats

Some Ceilometer Examples

How do these alarms work?


MEMAlarmHigh:
type: OS::Ceilometer::Alarm
properties:
counter_name: cpu_util
statistic: avg
period: '60'
evaluation_periods: '1'
threshold: '50'
alarm_actions:
- {"Fn::GetAtt": [ServerScaleUpPolicy, AlarmUrl]}
matching_metadata: {'metadata.user_metadata.server_group': 'ServerGroup'}
comparison_operator: gt

You will notice the matching_metadata, this is how Ceilometer finds the applicable samples to
calculate the Alarm. When ever we create a server we add metering.InstanceId=x and when ever
we create an autoscaling group we add metering.group=x to the server’s metadata.
Then Ceilometer looks for metadata with the prefix metering. and adds that to the sample metadata.
Have a look here: https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/util.py#L34
Just remember if you are using cfn-push-stats or even ceilmeter client directly this renaming does not happen
and you will need to search for metering. and not user_metadata..

With builtin metrics

https://github.com/asalkeld/autoscaling-testing/tree/master/Ceilometer

With in guest agent

https://github.com/asalkeld/autoscaling-testing/tree/master/Ceilometer_cfn_push_stats

Some potential reasons that your Alarms don’t work:

1) cfn-push-stats is out of date and has a bug – at one point it had a bug that pervented samples from being sent
2) The Ceilometer pipeline interval is too slow (needs to ~60 secs) https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/pipeline.yaml
3) check the matching_metadata to see if it is correct (use ceilometer -d sample-list -m ) check what the metadata actual is.
4) we have a bug in Heat:-O – head over to #heat and ask for help.

Things we need to do

1) make this more consistent
2) add all those combinations to integration tests
3) look at adding Monasca Alarms (if possible)
4) remove the builtin cloud watch implementation (it’s now deprecated)


by ahsalkeld at September 25, 2014 09:53 AM

Rafael Knuth

Recording & Slides: Turning OpenStack Swift into a VM storage platform

In case you missed our most recent OpenStack Online Meetup, please find both recording and slides...

September 25, 2014 09:17 AM

eNovance Engineering Teams

Journey of IPv6 in OpenStack

With the exhaustion of IPv4 addresses, IPv6 is no longer a choice but is now a necessity, even more so in case of a cloud environment.

Neutron includes a sub-team focused on bringing parity between IPv4 and IPv6 features and to enhance IPv6 support in OpenStack. The group currently meets every Tuesday at 15:00 UTC in #openstack-meeting-alt with notes available at the following link.

In this post, I would like to share my views on how IPv6 support has evolved in OpenStack with references at appropriate places to where you will be able to find more information.  I will try to first cover what is available in IceHouse, then review what has been merged in Juno and then talk about what is brewing for Kilo.

IceHouse: Limited Support

Support for IPv6 subnets

In order to create IPv6 subnets two new attributes, ipv6-ra-mode and ipv6-address-mode, were added to the Neutron Subnet API. Using these two attributes, you will be able to create subnets which support various IPv6 configuration modes like Stateless Address Autoconfiguration (SLAAC), DHCPv6 Stateful and DHCPv6 Stateless. Not all combinations of these parameters are valid. You can refer to the following link (and also here) which explain the valid/invalid use-cases.

IPv6 SLAAC: It allows an IPv6 compliant node to autonomously generate an IPv6 globally unique address using a combination of locally available information and information advertised by routers.

DHCPv6 Stateless Support: IPv6 addresses are auto discovered from the Router and additional info (like DNS) from DHCPv6 Server.

DHCPv6 Stateful Support: IPv6 addresses along with additional information is discovered from DHCPv6 Server.

IPv6 Upstream Provider Network Support (IceHouse)

With the IceHouse release of OpenStack, only IPv6 Upstream Provider Network support with VLANs is feasible. Some related patch-sets were merged in Juno timeframe and have to be manually backported to realise this feature.

Juno: we’re getting there

RADVD instead of DNSMASQ for RA (Juno)

During the Juno development cycle, some important decisions were taken. I would like to particularly highlight the decision taken to use RADVD over DNSMASQ for serving Router Advertisements (RA). The initial idea was to use DNSMASQ for all the IPv6 modes, but keeping in view of some of the roadmap features of IPv6 and the limitations of DNSMASQ it was decided to use RADVD for serving RAs and DNSMASQ for DHCPv6 Stateless/Stateful modes.

The main reasons behind this decision are mentioned below and are explained in the RADVD Blueprint.

  1. In an IPv6 SLAAC network, clients would configure the default gateway to the IP address of the NIC serving RA. Currently DNSMASQ runs in a separate dhcp namespace. So, to address the default gateway use-case, we have to either run another instance of DNSMASQ in the router namespace or change the existing behavior of Neutron to run the DNSMASQ in the router namespace instead of dhcp namespace. This could have implications for IPv4 use-cases as there could be some valid reasons behind running DNSMASQ in a separate dhcp namespace.
  2. RADVD has the support for Unicast RA, while DNSMASQ does not support it. Unicast RA would be required for floating IPv6 support and future additions to Neutron. The maintainer of DNSMASQ clearly suggests using RADVD over DNSMASQ for this purpose.

Multiple IPv6 configuration modes (Juno)

In Juno release, all the IPv6 configuration modes like SLAAC, DHCPv6 Stateful and Stateless modes will be supported. Along with this, IPv6 Security Groups support is now matured in OpenStack.

SLAAC Support: IPv6 addresses are auto discovered and assigned.

  1. BP Specification: Support Router Advertisement Daemon (radvd) for IPv6.
  2. Associated Patch: Radvd Support for IPv6 Router Advertisements.

DHCPv6 Stateless Support: IPv6 addresses auto discovered from the Router and additional info from DHCPv6 Server.

DHCPv6 Stateful: IPv6 addresses along with additional information discovered from DHCPv6 Server.

  1. BP Specification: Specification for Dnsmasq DHCPv6
  2. Launchpad Links: DHCPv6 Stateful, DHCPv6 Stateless.
  3. Associated Patch: Support Stateful and Stateless DHCPv6 by dnsmasq

What about the clients? Yes, the required changes are merged in python-neutronclient as well as Horizon.

ipv6-attributes

 

Network Connectivity with Neutron

This is a simplified architecture diagram of Network connectivity in OpenStack.

topology2

Note: As a platform requirement, we require DNSMASQ 2.63 (or above) and RADVD for IPv6 support.

As IPv6 support was improving in Neutron (Juno), one thing that was completely missing was the support for IPv6 in tempest. eNovance along with Comcast worked towards addressing the parity between IPv4 and IPv6 use-cases. I’m happy to see new patches submitted by various contributors in this regard.

Current limitations for Juno

There are some known limitations and areas where IPv6 impact is yet to be carefully evaluated like (not an exhaustive list)….

  1. Metadata is only supported on an IPv4  network. As a temporary measure, config-drive is a recommended solution.
  2. Impact on advanced features like FWaaS, VPNaaS etc.
  3. Privacy extensions is currently not supported as port-firewalling requires predictable addresses.
  4. Floating IPv6 support.
  5. Impact of IPv6 on overlay networks like GRE and VxLAN.
  6. IPv6 and NFV use-cases.

What about DevStack?

Unfortunately, at this time, DevStack currently does not support IPv6. The following patches are submitted in this regard, hoping that they will be implemented in Kilo.

  1. Add IPv6 support for tenant data network
  2. Add IPv6 management network support

Kilo: the final frontier?

What is in the Roadmap for Kilo?

In the Kilo Release, the following additional features are being proposed.

  1. IPv6 prefix delegation support in Neutron
  2. Support Multiple IPv6 Prefixes and Addresses for an IPv6 Network
  3. Support for dual-stack (IPv4 and IPv6) on external gateway
  4. Support IPv6 DHCPv6 Relay Agent
  5. IPv6 Floating IP support

This is an excellent news for all of us who are interested in OpenStack IPv6 support. While there is still a long way to go before we can say OpenStack is IPv6 production ready, it’s an important milestone as it gives us a platform where we can create IPv6 subnets, try out various use-cases and report issues that are encountered. Click here to see the IPv6 bugs reported in OpenStack.

Thanks to Sean M Collins, Xu Han Peng, Shixiong, HenryG, Baodong Li who implemented the IPv6 blueprints. While I have only mentioned few members who have addressed the blueprints, it was/is a collaborative effort from the Community (including the Neutron cores) who reviewed the patches, addressed issues and shared their knowledge at various stages.

by Sridhar Gaddam at September 25, 2014 06:58 AM

September 24, 2014

The Official Rackspace Blog » OpenStack

Deploying Humanitarian Applications On OpenStack At Grace Hopper Open Source Day

In October, Rackers will once again take OpenStack to the Grace Hopper Celebration of Women in Computing! As OpenStack sharpens its focus on the super user, we will as well with this year’s Open Source Day. The focus of the Open Source Day is humanitarian projects, and Grace Hopper conference organizers want female developers to learn how to contribute to them. Beside OpenStack, this year’s participating projects include Microsoft Disaster Response, Ushahidi’s initiative CrisisNET, the Sahana Eden humanitarian platform and others. Check out all of the Open Source participants here: http://gracehopper.org/open-source-day/.

Last year, Iccha Sethi and Anne Gentle organized an all-day OpenStack hackathon. Along with fellow OpenStack volunteers, Iccha and Anne led Grace Hopper attendees in a workshop on how to contribute to OpenStack. The Open Source Day was a huge success, and participants were exposed to the process of contributing code to OpenStack — a few participants even submitted code patches.

The group at Open Source Day 2013.

This year, Iccha Sethi, Egle Sigler and Dana Bauer, along with other Rackers and OpenStackers, will lead a workshop for developers on how to deploy humanitarian applications on OpenStack. Developing code is not always enough, as a lot of developers experience when they need to figure out where and how to deploy their applications. Deployment, scalability and high availability are even more important to applications focused on scenarios where sudden load and traffic spikes are expected, for example during a disaster. Throughout the workshop, participants will learn how to deploy their humanitarian applications by spinning up servers, load balancers, databases and other essential infrastructure components, as well as learn how to monitor and scale them when needed.

Iccha Sethi explains OpenStack architecture for the participants at Open Source Day 2013.

Open Source Day is Wednesday, October 8 during the Grace Hopper conference. In addition to learning about OpenStack during Open Source Day, Grace Hopper attendees can also learn about different types of clouds by attending Egle’s and Iccha’s session “Deploying Your Application On Public Cloud” Thursday, October 9 at 10:15 a.m. During the workshop, Egle and Iccha will explain the differences between various clouds and address common cloud buzzwords like server, image, snapshot, PaaS, IaaS, SaaS. From there, they’ll show attendees how to start using cloud tools by deploying their own application to the public cloud.

by Egle Sigler and Iccha Sethi at September 24, 2014 07:00 PM

Rich Bowen

What’s new in OpenStack Juno

Originally posted on opensource.com.

OpenStack is on a six-month release cycle, with each release given  a code name starting with consecutive letters of the alphabet. On October 16th, OpenStack Juno will be released, with several new projects, and lots of new features.

Here’s a few of the things you can expect in the next release of
OpenStack. This isn’t intended to be comprehensive – just a taste of
some of the things that are coming.

Nova

As the core of OpenStack, Nova needs to be solid. But this doesn’t mean that it’s slow to change, with some significant changes coming in Juno.

* NFV

NFV – Network Function Virtualization – is a big deal lately, and you
can look to see lots of people working on it, as well as vendors talking about it.

* Live Upgrades

First introduced in Icehouse, live upgrades were still a little rocky.
You’ll see big improvements in this area in Juno.

* More

See more of what’s coming in Juno in Russell Bryant’s blog post at
http://blog.russellbryant.net/2014/07/07/juno-preview-for-openstack-compute-nova/

Ceilometer

Ceilometer is the metering/measurement component of OpenStack.

* Speed

Over the last few cycles, the Ceilometer team have identified some
poorly-designed parts of the project, and have taken a lot of time this cycle to pay down the technical debt to regain some of the performance lost to those decisions. So you can look for Ceilometer to be much more efficient, and faster, in Juno.

* Community reboot

The project management is moving from a top-down decision making process to a collaborative community decision making process, so that everyone has a voice in how decisions are being made.

Additionally, some controls are being put in place regarding the code freeze at the end of the cycle, so that people aren’t trying to rush new functionality in at the last minute, resulting in testing gaps.

* QA

Speaking of testing, there’s also an effort to ensure more Tempest and Grenade test coverage in Juno, which should ensure better code
reliability.

* More

See more of what’s coming in Juno in this interview with Eoghan Glynn of the Ceilometer community:
http://community.redhat.com/blog/2014/07/upstream-podcast-episode-10-rich-bowen-with-eoghan-glynn-on-openstack-juno/

Heat

Heat is the orchestration component of OpenStack, which can be used to set up and tear down infrastructure automatically in response to environmental events, or scripted.

* Rollback

In the past, if a Heat deploy failed, you just moved on, and maybe went back and cleaned up by hand. In Juno, it will be easier to roll back a failed deployment, and be sure that all of the various pieces have been cleaned up.

* Create resources without being admin

In Icehouse and earlier, certain types of resources could only be
created as admin. In Juno, creating users will still require that you be
admin, but you can then delegate privileges to that user so that they
can create resources without having to be admin.

* More

Read more about what’s coming in Juno for Heat at
http://www.zerobanana.com/archive/2014/07/10#heat-juno-update

Glance

Glance is “a service where users can upload and discover data assets
that are meant to be used with other services, like images for Nova
and templates for Heat.” This is a new mission statement in Juno, and some of the changes that are coming are:

* Artifacts

The scope is expanding in Juno to be more than just an image registry, to being a generic catalog of various data assets. This will allow for greater flexibility in how it can be used.

* More

Read more about what’s coming in Juno for Glance at
http://blog.flaper87.com/post/juno-preview-glance-marconi/

Marconi

Marconi (Now renamed to Zaqar) is OpenStack’s messaging and queuing system, and so is very important to all of the other components.

* Redis

In Juno, Zaqar will add a storage driver to support redis, and
support for storage engines is in the works. It will be possible to create and tag clusters of storage and then use them based on their capabilities.

* Queues migration

The Zaqar team will be adding support for queues migration between pools of the same type. Read more at
https://blueprints.launchpad.net/marconi/+spec/queue-migration

* More

Flavio’s article at
http://blog.flaper87.com/post/juno-preview-glance-marconi/ also covers Zaqar, as well as Glance.

Keystone

Keystone is the identity management piece of OpenStack, and has some big improvements coming in Juno.

* LDAP integration

Using Keystone against a database is ok, in that it does password
authentication. But what you really want is to integrate it with your
existing user authentication infrastructure. This often means LDAP. In Juno, you can configure Keystone to use multiple identity backends, and integration with LDAP will be much easier.

* Other security projects

The same community that works on Keystone is also very interested in other security related projects in the OpenStack ecosystem. Look for projects Barbican and Kite to be more active in the coming months.

* More

Nathan Kinder’s article at
http://redhatstackblog.redhat.com/2014/08/05/juno-updates-security/ covers more of what’s coming in Juno. See also this blog post: https://blog-nkinder.rhcloud.com/?p=130 for clarification of some of these goals.

TripleO

TripleO is a project about installing, upgrading, and operating
OpenStack clouds in an automated fashion. This is a big area of interest in Juno – making OpenStack easier to deploy and manage.

* High Availability

A big push in Juno is deploying HA clouds with TripleO. This will be the default behavior, which has the added benefit of getting everyone testing HA deployments, even on “clusters” as small as 1 node.

* Heat templates

TripleO uses Heat as part of the automation of deployment. So in Juno a lot of work has gone into the Heat templates that are used.

* More

Read more about what’s coming in Juno for TripleO in James Slagle’s blog post at http://blog-slagle.rhcloud.com/?p=235

Horizon

Horizon is the web admin interface for OpenStack. While many people will interact with OpenStack via the command line and APIs, the web interface is still the face of OpenStack for many OpenStack operators.

* Sahara (Hadoop)

Sahara is a new project that makes it easier to deploy Apache Hadoop or Apache Spark on OpenStack. This project has graduated, and so it’s now integrated into the dashboard, so you can deploy Hadoop clusters with a few mouse clicks.

* JavaScript unbundling

As good Open Source citizens, Horizon has moved to unbundling the
Javascript libraries that were previously copied into the Horizon source tree. This not only makes it easier to manage upgrades, but also complies with no-bundling requirements in certain Linux distros like

* More

See more about what the Horizon team is doing for Juno in Matthias
Runge’s blog post at http://www.matthias-runge.de/2014/09/08/horizon-juno-cycle-features/

See also

This is just a sampling of what’s coming in Juno. As well as reading all
of the excellent articles at https://openstack.redhat.com/Juno_previews
see also the YouTube playlist of PTL (Project Technical Lead) webinars.

And come to the OpenStack Summit in Paris to see what we’ll do for an encore in Kilo.

by rbowen at September 24, 2014 06:41 PM

Percona

Percona Server, OpenStack and the Tesora DBaaS Platform

Percona Server, OpenStack and the Tesora DBaaS PlatformPercona Server and Percona XtraDB Cluster provide high-performance alternatives for MySQL users. We have also seen rapidly growing interest in these solutions in the OpenStack community where higher performance and high availability are crucial. Many OpenStack users are adopting these solutions but we’ve also seen demand from companies creating OpenStack distros. For example, Percona XtraDB Cluster is now certified for the RHEL OSP (OpenStack Platform) and is included in the Ubuntu 14.04 LTS release. Tesora recently joined this rapidly growing list when they announced the Tesora DBaaS Platform Enterprise Edition which includes Percona Server.

The Tesora platform is an enterprise-ready database as a service (DBaaS) platform based on the OpenStack Trove project. Percona Server was certified by Tesora in August as part of their Tesora DBaaS Platform certification program.

What does this mean for you if you are one of the users who have downloaded Percona Server more than 1,000,000 times?

Many enterprises are evaluating how to deliver robust, high-performance MySQL-as-a-service. OpenStack Trove is is an open-source platform that addresses this challenge. OpenStack operators can build and offer multiple databases as a service (such as MySQL, MongoDB, or Redis). These users can create, operate, maintain and delete different kinds of SQL or NoSQL databases on demand. Users don’t need to worry about the administrative details of the database technology nor complexities such as availability, resiliency, backups, recovery and security.

The Tesora DBaaS Platform Enterprise Edition builds upon OpenStack Trove and makes the “provisioning, deployment, configuration, tuning, monitoring and administration” simpler for operators. The platform includes support for multiple database backends including Percona Server which is certified on the Tesora DBaaS platform. Administrators and DBAs looking to build and offer a database as a service using the Tesora DBaaS Platform Enterprise Edition can rest assured that Percona Server is ready to meet their needs.

OpenStack is a rapidly evolving open-source platform that depends heavily on MySQL for optimal performance. Percona is participating in the Trove project and is sharing our knowledge on OpenStack through webinars (such as “OpenStack: A MySQL DBA Perspective“), blog posts (such as “OpenStack users shed light on Percona XtraDB Cluster deadlock issues“), professional services (such as Percona Consulting Services) and the recently announced OpenStack Live Conference which will be held April 13-14 2015 at the Santa Clara Convention Center in Silicon Valley (the Call for Speakers is open until November 9!).

We look forward to working with Tesora as they build out their platform as well as the rest of the OpenStack community as this exciting technology continues to mature. I hope you can join us in Santa Clara for the OpenStack Live Conference this April – submit your speaker proposal now or purchase your ticket at Super Saver prices!

The post Percona Server, OpenStack and the Tesora DBaaS Platform appeared first on MySQL Performance Blog.

by Tushar Katarki at September 24, 2014 03:13 PM

Tesora Corp

Short Stack: HP number one OpenStack contributor, Red Hat all in on cloud and simplifying OpenStack

short stack_b small_0_0.jpgWelcome to the Short Stack, our weekly feature where we search for the most intriguing OpenStack links to share with you. These links may come from traditional publications or company blogs, but if it's about OpenStack, we'll find the best links we can to share with you every week.

If you like what you see, please consider subscribing.

Here we go with this week's links:

HP leapfrogs Red Hat to become top contributor to OpenStack | Network World

HP has been all over OpenStack this year, so I suppose it shouldn't be a complete surprise that when the latest contributor statistics came out, it had passed RedHat as the number one contributor to Juno. Red Hat can't be pleased.

Red Hat CEO announces a shift from client-server to cloud computing | ZDNet

Not when Red Hat announced this week, it recognizes the future of its business is in the cloud and particularly in OpenStack. This was a huge acknowledgement on its part because enterprise Linux is at the core of the company's history and to this point, its bread and butter product.

Simplifying OpenStack | Walking Contradiction

Let's face it, OpenStack is a complex project (as I wrote about in this blog earlier this week), and companies are looking for simpler ways of delivering it. This writer is looking for a simpler way to conceptualize it and that in itself could help other developers trying to understand it.

Apcera scores big, undisclosed, investment from Ericsson for its enterprise IT platform | GigaOm

Ericsson invested in startup Apcera last week and it's an interesting partnership. While Ericcson, like every other big company under the sun recognizes that they have to embrace OpenStack (and they are), this investment is about filling in a hole they see in OpenStack in companies that have to link to a variety of legacy systems.

Key Cisco defections in data center, OpenStack | Network World

Meanwhile, the politics of OpenStack continues as we see key players hopping around and moving between cloud vendors. Recently, former Red Hat CIO Brian Stevens joined Google Cloud. Now some key folks at Cisco are pulling up stakes and joining rivals with one heading to VMware and the other...wait for it...HP.

by 693 at September 24, 2014 10:33 AM

Flavio Percoco

Zaqar's pools explained

Now that I've dedicated time to explain what Zaqar's path going forward is (Zaqar being a messaging service akin to SQS/SNS), I can move on and spend some time diving into some of Zaqar's internals. For this post, I'd like to explain how Zaqar's pools work.

Zaqar's scalability is more than just adding web heads or scaling the storage backend. Although both sides can scale horizontally to support big scales, there's still a chance for the storage backend to hit a limit where it needs to offload traffic to other clusters in order to keep scaling. This is where pools come handy.

Essentially, pools are storage clusters[0]. You could think about pools as you'd think about shards. They are independent and isolated storage nodes that contain part of the data stored in the system. You can add as many pools as you need, although it is recommended to scale each pool as much as possible before adding new ones.

Pools can be more than just a way for scaling Zaqar's storage but for the sake of this post, I'll just explain how they work.

Let me start by explaining how data is split across pools.

Zaqar balances data across pools in a per-queue basis. That means, message distribution happens within the storage cluster and it's not done by Zaqar itself - there are some reasons to it (some of them explained here) that I won't go through in this post.

As I've already mention in the past, distributing queues - buckets, containers, whatever - is not as effective as distributing messages. Doing distribution at a queue level has intrinsic limitations - like hard to balance storage nodes - that could be overcome by pushing distribution down to a message level. The later, however, brings in a whole lot of other issues that Zaqar is not willing to support just yet.

When pools were added, the team considered a set of algorithms that could be used to help balancing queues. Some of those algorithms didn't require much intervention from the operator side - like a hashring - whereas others - like a weight-based algorithm - require the operator to know it's loads, clusters distribution and capabilities. After having considered the available algorithms and the feedback from operators, the team chose to start with a weighted algorithm - we've been discussing supporting more algorithms in the future, but as of now there's just one - that would give deployers enough control over how data is distributed across pools and that would also make it easier to change the results of the algorithm easily and cheap. For example, if a pool wants to be dismissed, it's possible to set its weight to 0 and prevent it to get new queues.

The current weighted algorithm looks like this:

def weighted(objs, key='weight', generator=random.randint):
    """Perform a weighted select given a list of objects.

    :param objs: a list of objects containing at least the field `key`
    :type objs: [dict]
    :param key: the field in each obj that corresponds to weight
    :type key: six.text_type
    :param generator: a number generator taking two ints
    :type generator: function(int, int) -> int
    :return: an object
    :rtype: dict
    """
    acc = 0
    lookup = []

    # construct weighted spectrum
    for o in objs:
        # NOTE(cpp-cabrera): skip objs with 0 weight
        if o[key] <= 0:
            continue
        acc += o[key]
        lookup.append((o, acc))

    # no objects were found
    if not lookup:
        return None

    # NOTE(cpp-cabrera): select an object from the lookup table. If
    # the selector lands in the interval [lower, upper), then choose
    # it.
    gen = generator
    selector = gen(0, acc - 1)
    lower = 0
    for obj, upper in lookup:
        if lower <= selector < upper:
            return obj
        lower = upper

NOTE: Something to note about the current algorithm is that it doesn't take into account the number of queues that exist in each pool, which is something that could be added to it. Also, if you've any feedback as to how this algorithm can be improved, please, let us know - #openstack-zaqar @ freenode.

The above algorithm is used just once per queue. When a queue is created, the pooling driver looks up for an available pool and then registers the queue there. A registry that maps queues and pools is kept in a catalogue that is then queried to lookup the pool a queue has been registered into.

Right after the queue is registered in a pool, all the operations on that queue will happen in that specific pool. However, global operations like getting statistics, examine cluster's health or even listing queues will happen across all the available pools.

Pools' concept is very simple and the implementation has lots of room for improvements that we'd love to explore. In the future, it'd be useful to have support for queue's migration with 0 downtime and obviously no data loss. Moreover, we'd also like to have support for other algorithms that would help balancing queue's as even as possible without depending on the operator.

This is all I've to say about Zaqar's pools. If there's anything that looks broken or could be improved, please let us know or even better, contribute ;)

[0] Note that cluster refers to a replicated, fully reliable storage deployment. For example, a mongodb cluster could be either a replica set or a sharded mongodb environment.

by FlaPer87 at September 24, 2014 07:28 AM

Opensource.com

What's new in OpenStack Juno

OpenStack is on a six-month release cycle, with each release given a code name starting with consecutive letters of the alphabet. On October 16th, OpenStack Juno will be released, with several new projects, and lots of new features. Here's a few of the things you can expect in the next release of OpenStack. This isn't intended to be comprehensive—just a taste of some of the things that are coming.

by rbowen at September 24, 2014 07:00 AM

Robert Collins

what-poles-for-the-tent

So Monty and Sean have recently blogged about about the structures (1, 2) they think may work better for OpenStack. I like the thrust of their thinking but had some mumblings of my own to add.

Firstly, I very much like the focus on social structure and needs – what our users and deployers need from us. That seems entirely right.

And I very much like the getting away from TC picking winners and losers. That was never an enjoyable thing when I was on the TC, and I don’t think it has made OpenStack better.

However, the thing that picking winners and losers did was that it allowed users to pick an API and depend on it. Because it was the ‘X API for OpenStack’. If we don’t pick winners, then there is no way to say that something is the ‘X API for OpenStack’, and that means that there is no forcing function for consistency between different deployer clouds. And so this appears to be why Ring 0 is needed: we think our users want consistency in being able to deploy their application to Rackspace or HP Helion. They want vendor neutrality, and by giving up winners-and-losers we give up vendor neutrality for our users.

Thats the only explanation I can come up with for needing a Ring 0 – because its still winners and losers (e.g. picking an arbitrary project) keystone, grandfathering it in, if you will. If we really want to get out of the role of selecting projects, I think we need to avoid this. And we need to avoid it without losing vendor neutrality (or we need to give up the idea of vendor neutrality).

One might say that we must pick winners for the very core just by its, but I don’t think thats true. If the core is small, many people will still want vendor neutrality higher up the stack. If the core is large, then we’ll have a larger % of APIs covered and stable granting vendor neutrality. So a core with fixed APIs will be under constant pressure to expand: not just from developers of projects, but from users that want API X to be fixed and guaranteed available and working a particular way at [most] OpenStack clouds.

Ring 0 also fulfils a quality aspect – we can check that it all works together well in a realistic timeframe with our existing tooling. We are essentially proposing to pick functionality that we guarantee to users; and an API for that which they have everywhere, and the matching implementation we’ve tested.

To pull from Monty’s post:

“What does a basic end user need to get a compute resource that works and seems like a computer? (end user facet)

What does Nova need to count on existing so that it can provide that. “

He then goes on to list a bunch of things, but most of them are not needed for that:

We need Nova (its the only compute API in the project today). We don’t need keystone (Nova can run in noauth mode and deployers could just have e.g. Apache auth on top). We don’t need Neutron (Nova can do that itself). We don’t need cinder (use local volumes). We need Glance. We don’t need Designate. We don’t need a tonne of stuff that Nova has in it (e.g. quotas) – end users kicking off a simple machine have -very- basic needs.

Consider the things that used to be in Nova: Deploying containers. Neutron. Cinder. Glance. Ironic. We’ve been slowly decomposing Nova (yay!!!) and if we keep doing so we can imagine getting to a point where there truly is a tightly focused code base that just does one thing well. I worry that we won’t get there unless we can ensure there is no pressure to be inside Nova to ‘win’.

So there’s a choice between a relatively large set of APIs that make the guaranteed available APIs be comprehensive, or a small set that that will give users what they need just at the beginning but might not be broadly available and we’ll be depending on some unspecified process for the deployers to agree and consolidate around what ones they make available consistently.

In sort one of the big reasons we were picking winners and losers in the TC was to consolidate effort around a single API – not implementation (keystone is already on its second implementation). All the angst about defcore and compatibility testing is going to be multiplied when there is lots of ecosystem choice around APIs above Ring 0, and the only reason that won’t be a problem for Ring 0 is that we’ll still be picking winners.

How might we do this?

One way would be to keep picking winners at the API definition level but not the implementation level, and make the competition be able to replace something entirely if they implement the existing API [and win hearts and minds of deployers]. That would open the door to everything being flexible – and its happened before with Keystone.

Another way would be to not even have a Ring 0. Instead have a project/program that is aimed at delivering the reference API feature-set built out of a single, flat Big Tent – and allow that project/program to make localised decisions about what components to use (or not). Testing that all those things work together is not much different than the current approach, but we’d have separated out as a single cohesive entity the building of a product (Ring 0 is clearly a product) from the projects that might go into it. Projects that have unstable APIs would clearly be rejected by this team; projects with stable APIs would be considered etc. This team wouldn’t be the TC : they too would be subject to the TC’s rulings.

We could even run multiple such teams – as hinted at by Dean Troyer one of the email thread posts. Running with that I’d then be suggesting

  • IaaS product: selects components from the tent to make OpenStack/IaaS
  • PaaS product: selects components from the tent to make OpenStack/PaaS
  • CaaS product (containers)
  • SaaS product (storage)
  • NaaS product (networking – but things like NFV, not the basic Neutron we love today). Things where the thing you get is useful in its own right, not just as plumbing for a VM.

So OpenStack/NaaS would have an API or set of APIs, and they’d be responsible for considering maturity, feature set, and so on, but wouldn’t ‘own’ Neutron, or ‘Neutron incubator’ or any other component – they would be a *cross project* team, focused at the product layer, rather than the component layer, which nearly all of our folk end up locked into today.

Lastly Sean has also pointed out that we have large N N^2 communication issues – I think I’m proposing to drive the scope of any one project down to a minimum, which gives us more N, but shrinks the size within any project, so folk don’t burn out as easily, *and* so that it is easier to predict the impact of changes – clear contracts and APIs help a huge amount there.


by Robert Collins at September 24, 2014 04:13 AM

Mirantis

What’s New about Mirantis OpenStack 5.1

Mirantis OpenStack 5.1 has just been released, and with it comes several new enhancements.  These features include an experimental preview of features that are technically complete but still require some testing to ensure that they stand up within real world environments.  We’ve done this to enable our customer and community base to review and use the features in controlled environments and then provide feedback – so we strongly encourage you to try them out and let us know what you think!

 Like 5.0.1 before it, you can upgrade Mirantis to OpenStack 5.1 in place and still manage your existing environments deployed by version 5.0 or 5.0.1.  The Fuel Master Node retains the ability to add and delete nodes and perform other operational functions such as log management and Health Checks.  

In addition, here’s a rundown of some of the newly added features:

Fuel is now protected by access control

When using either the Fuel UI or Fuel APIs, users will be asked to provide authentication credentials (e.g. username and password). These credentials and the authentication process are handled by a local instance of Keystone that is present on the Fuel Master Node. Users can change their passwords within the Fuel UI.

  

VMware NSX is now supported as a network option

Mirantis OpenStack 5.1 enables you to select VMWare NSX, a software-defined networking (SDN) option that uses controllers and overlay networking, as a networking choice.   You can configure this integration from the UI before deployment.

The Fuel Master Node can now be backed up and restored

Building on the Docker packaging architecture introduced in Mirantis Openstack 5.0, the current state of the Fuel Master Node can now be backed up and, if necessary, restored. This is done from the command line in Mirantis OpenStack 5.1.

vCenter integration has been enhanced

The ability to utilize vCenter ESXi servers as compute resources for OpenStack was introduced in Mirantis OpenStack 5.0. In Mirantis OpenStack 5.1, this integration has been enhanced in the following ways:

  • Fuel can now be configured to utilize multiple vCenter clusters. This can be accomplished by entering multiple vCenter cluster names into the Cluster field in the Settings Tab, separating the cluster names with commas.

  • vCenter integration now provides high availability for the Nova-compute service.

  • The compute service used to communicate with vCenter is now deployed on multiple controllers (if available), thus making the implementation highly available.

  • The vCenter Virtual Machine Disk (VMDK) can be utilized as a back-end for Cinder utilizing the standard upstream VMWare VMDK Cinder driver. Cinder LVM is no longer supported as a storage option for vCenter.

SR-IOV based networking and ISER block storage over the Mellanox ConnectX-3 adapter family are supported

Mirantis OpenStack can now properly detect Mellanox hardware that is installed on discovered nodes and enable an operator to:

  • Configure storage to work over iSER (High performance iSCSI protocol over RDMA).

  • Install OFED drivers, firmware and configure SR-IOV kernel parameters.

  • Install and configure Mellanox SR-IOV plugin for OpenStack (included in the ML2 plugin) for high performance VM links.

  • Test the environment using Mirantis OpenStack Health Checks.

Ceph storage platform has been updated to Firefly

Mirantis OpenStack 5.1 deploys the Ceph version 0.80.4 (“Firefly”). Previous versions of Mirantis OpenStack deployed the Ceph version 0.67.x (“Dumpling”).

Enhanced High Availability Architecture

Mirantis OpenStack 5.1 includes fixes and improvements for a number of OpenStack issues related to the stability and scalability of Highly Available clusters. These fixes have been contributed to the community for possible inclusion in future OpenStack distributions. These fixes are related to the architectural modifications made to Fuel in Release 5.1 and so are not included in the 5.0.2 release.

(Experimental) Fuel can now perform a minor update of existing Mirantis OpenStack environments

In Mirantis OpenStack 5.1, we’ve introduced an experimental feature that enables the Fuel Master Node to perform a minor update to existing Mirantis Openstack environments using Mirantis OpenStack packages provided by Mirantis. You can update an existing environment to a newer stable release automatically through the UI with a single button push.  

For example, Mirantis OpenStack 5.0 is based on the 2014.1 version of Icehouse. Mirantis OpenStack 5.1 contains the packages required to update an Icehouse 2014.1 OpenStack environment (deployed with 5.0) to Icehouse 2014.1.1. In Mirantis OpenStack 5.1, this update package is labeled as “2014.1.1-5.0.2” and the upgrade feature is available from the Actions tab in the Update panel.

(Experimental) Zabbix can be installed as a monitoring solution

Also, when the experimental feature group is enabled, Mirantis OpenStack can now deploy the Zabbix solution to monitor network and server devices as well as OpenStack services. The Zabbix server can be selected as a role to be deployed onto a discovered node; Zabbix agents are automatically deployed onto all other OpenStack nodes in the environment.

Zabbix comes with some standard templates for monitoring the operating system and general health of a server.  We’ve also added templates that enable you to monitor OpenStack services, High Availability processes and other components utilized by OpenStack (e.g. mySQL).  

 

Conclusion

We’re extremely excited about this newest release of Mirantis OpenStack.  It delivers on several features requested by both customers and the wider community.  It continues to provide a stable and reliable infrastructure choice to run production workloads.  And it makes all this available through an easy to use lifecycle management application.  We hope you download and utilize Mirantis OpenStack 5.1 and see for yourself!

The post What’s New about Mirantis OpenStack 5.1 appeared first on Mirantis | The #1 Pure Play OpenStack Company.

by David Easter at September 24, 2014 12:20 AM

September 23, 2014

Cloudwatt

Swiftpolicy, or how I learned to stop worrying and love the permissions

Fine-grain control of permissions in OpenStack Swift can be done natively using Access Control Lists. Unfortunately, this was not enough to cover some use cases we have here at Cloudwatt. We needed a way to manage permission for multiple profiles, based on roles assigned to each user. In order to solve this problem, we wrote a middleware that adds proper permission control via a policy.json file, the same way other OpenStack components deal with this issue. The middleware is called Swiftpolicy and is available on Stackforge.

Installation

Installing swiftpolicy can be done from source. Here’re simple steps to follow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ virtualenv swiftpolicy_env
New python executable in swiftpolicy_env/bin/python2.7
Also creating executable in swiftpolicy_env/bin/python
Installing setuptools, pip...done.

$ source swiftpolicy_env/bin/activate

(swiftpolicy_env)$ git clone https://github.com/cloudwatt/swiftpolicy.git
Cloning into 'swiftpolicy'...
remote: Counting objects: 172, done.
remote: Total 172 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (172/172), 46.93 KiB | 0 bytes/s, done.
Resolving deltas: 100% (81/81), done.
Checking connectivity... done.

(swiftpolicy_env)$ cd swiftpolicy

(swiftpolicy_env)$ pip install -r requirements
Downloading/unpacking dnspython>=1.9.4 (from -r requirements (line 1))
...
...
...
Successfully installed dnspython eventlet greenlet netifaces pastedeploy simplejson xattr swift-1.13.0 six cffi pycparser
Cleaning up...

(swiftpolicy_env)$ python setup.py install

Note that these steps install the middleware in a virtualenv and therefore make sure to launch the swift proxy-server inside the same virtualenv. Depending on your use case, you might be able to ignore virtualenv altogether.

Configuration

Activating the middleware is done by including it in the Swift proxy pipeline. To do so, modify the proxy configuration file (usualy /etc/swift/proxy-server.conf). The simplest thing to do is replace the keystoneauth middleware with swiftpolicy.

Change:

1
2
[pipeline:main]
pipeline = catch_errors cache keystoneauth tempauth ... proxy-server

To:

1
2
[pipeline:main]
pipeline = catch_errors cache swiftpolicy tempauth ...  proxy-server

In the same file, include the proper section of the swiftpolicy WSGI filter:

~~~ linux-config [filter:swiftpolicy] use = egg:swiftpolicy#swiftpolicy policy = %(here)s/default.json ~~~

The policy directive indicates the path to the policy.json file. In this case, the file will be located in the same directory as the configuration file. Restart the proxy server and you’re done.

Policy file

The policy file will list all possible actions on a swift proxy. Action’s syntax is: <http verb>_<swift entity> (example: “get_container”, “put_object”, etc).

1
2
3
"get_container": "rule:allowed_for_user",
"put_container": "rule:allowed_for_user",
"delete_container": "rule:allowed_for_user",

The policy file contains also two specific rules: “swift_owner” “reseller_request”, they are defined when swift_owner and reseller_request headers are set to true, as those two values are part of the contract with the auth system (more details here)

1
2
"swift_owner": "rule:swift_reseller or rule:swift_operator",
"reseller_request": "rule:swift_reseller",

Example:

  • To forbid the creation of new containers: set put_container to ‘!’:
1
2
"get_container": "rule:allowed_for_user",
"put_container": "!",
  • To restrict the creation of new containers to users with the role “admin”:
1
2
"get_container": "rule:allowed_for_user",
"put_container": "role:admin",

Testing Swiftpolicy

Here’s how to test and validate the usage of the swiftpolicy middleware:

  1. Modify the policy json file to restrict creation of new containers to admin, as shown in the previous paragraph.
  2. Restart the swift-proxy (at the time of this writing, swiftpolicy doesn’t support dynamic reload of the policies).
  3. Test the creation of a container with a regular user, it should fail with a 403 error code
  4. Test the creation of a container with an admin, it should succeed.
1
2
3
4
5
6
7
8
9
10
11
$ source openrc demo demo password
$ swift list
$ swift post my_container
Container PUT failed: http://10.0.48.252:8080:8080/v1/AUTH_01b059eda9a24f66b84d9b72284d7369/my_container2 403 Forbidden  [first 60 chars of response] <html><h1>Forbidden</h1><p>Access was denied to this resourc
        
$ # as an admin
$ source openrc admin admin password
$ swift list
$ swift post my_container
$ swift list
my_container

by Joe H. Rahme at September 23, 2014 10:00 PM

IBM OpenStack Team

Creating your own continuous integration environment for OpenStack

Though OpenStack is a large and complex project at present, its development community is structured very well in comparison to other large open source projects or proprietary development practice communities, to the degree that OpenStack is even considered a role model. It is particularly interesting to note how this community has developed an infrastructure for code review, testing and continuous integration.

In this series of posts, I will discuss continuous integration (CI), looking at how the OpenStack community adopted this practice and the advantages of integrating your own CI environment into OpenStack. I will give a brief description of each of the main components and what you need to know in order to kick off your own services. This is not intended to be a tutorial, but I will provide links to several useful tutorials in my last post.

The OpenStack CI environment includes a series of projects that contain unit tests, functional tests, integration tests, a patch review system and automatic builds. Most of those projects are hosted within the OpenStack Infrastructure project and managed by the OpenStack Infrastructure Team, but tools like Tempest, DevStack and Grenade are essential to provide required automation and the environment that makes CI effective. Those systems are integrated with the build and patch review system (Gerrit), in order to provide the appropriate verification for every change proposed to OpenStack projects. This can ensure that usability, policies, reliability, security, dependencies and other environmental characteristics are properly maintained. Behind all this, you need a cloud infrastructure to run it all.

The first things to understand are how the patch review process works in OpenStack and what main tools are used to automate it.

CI diagram

Continuous integration flow

In the simplest terms, there are five steps in the process:

1. Someone submits a patch for review, which is then managed by Gerrit. Any configured CI environment may be listening for new patches on this service by a configured Zuul scheduler.

2. The Zuul gate receives those changes, and then checks for dependencies and merges changes.

3. The changes will then be handled as jobs by the build automation system Jenkins. Behind that. other tools will create the images and virtual machines to run the jobs (Nodepool) and automate the creation of the jobs that need to be tested on the environment (Jenkins Job builder).

4. Each project hosted by OpenStack has a set of job types. Depending on the specific purpose , each job may use existing open source tools and OpenStack projects such as Tempest and Devstack. A job can be used for the following purposes:

• Unit tests
• Code language checks (Python, pep and pylint)
• Integration tests (using Tempest and DevStack)
• Upgrade tests (using Grenade, DevStack and Tempest)

5. Finally, job results (failures and successes) are reported back to Gerrit and may influence patch reviews such as voting, verifying or even merging the patch code.

This whole procedure is automated. I mentioned a few services that are used in the process (such as Gerrit, Zuul, Nodepool, Jenkins), but there are other parts that you’ll need to make the whole system work. Those tools will be presented in the third post of this series.

Once you have a general understanding of how the CI system works, we can discuss why your company or group of developers may want to create your own CI environment, what you will need in order to accomplish that and what size infrastructure you should consider for your purposes.

Feel free to contact me on Twitter or LinkedIn, or leave a comment below to let me know of your own experiences with continuous integration environments

The post Creating your own continuous integration environment for OpenStack appeared first on Thoughts on Cloud.

by Adalberto Medeiros at September 23, 2014 07:44 PM

Tesora Corp

Deploying OpenStack and Trove (DBaaS) at eBay

eBay at Trove Day.pngAre you wondering how to deploy OpenStack in a production environment?  Take a look at this video presentation by eBay software engineers Mat Lowery and Auston McReynolds. For the first time, they tell the eBay story during OpenStack Trove Day. The team goes into great detail about how they configured the OpenStack cloud which serves for all eBay developers across the entire organization including their subsidiaries. 

As McReynolds says, "it's frictionless, no tickets and no people. It’s the easiest way to meet demand and let developers get their job done".

With the backdrop of OpenStack, Mat Lowery explains the deployment of Trove, the OpenStack DBaaS platform.  He shows how you can call up a database with a click of a button.  Today, eBay developers can choose from six different databases, enabling developer agility and operational efficiency. Take a look. Or you can view the slides here.

by 86 at September 23, 2014 03:19 PM

Flavio Percoco

Zaqar's path going forward

Long time since I wrote my last post about Zaqar (ex Marconi) and I thought this one should be a summary of what has happened and what will, probably, happen going forward.

Let me start by sharing where Zaqar is in OpenStack.

At every end of the cycle - ~6 weeks before it ends, to be precise - every incubated project goes through a review process where things like API stability, integration with the OpenStack ecosystem, community etc - full list - are revisited in order to evaluate the project and determine if it's ready to be part of the OpenStack integrated release. Despite Zaqar having met all those requirements, it was not accepted into the integrated release. The story is long and it's not the intent of this post to walk you through it. However, if you're interested in getting more details about what happened exactly please go here: 1st meeting 2nd meeting 3rd meeting 1st thread 2nd thread Review.

One thing to get from the last review process, and definitely keep in mind, is that Zaqar is ready to be used in production environments. Technically speaking it met all the requirements imposed by the TC and as a project it's had a stable API for quite a bit already.

One of the discussions that happened during the last graduation review was related to whether Zaqar is a queuing service or a messaging service. To me, and as Gordon Sim mentioned in this email there's no real difference between those 2 besides the later being a more generic term than the former. This discussion led to other discussions like whether things like get-message-by-id makes sense, whether keeping queuing semantics is necessary or even whether guarantees like FIFO should be kept.

All the above discussions have been interesting but I'd like to take a step back and walk you through a perhaps less technical topic but not less important. It's clear to me that not everyone knows what the project's vision is. So far, we've made clear what Zaqar's API goals are, what kind of service Zaqar is and the use-cases it tries to address but we haven't neither explicitly explained nor documented well-enough what Zaqar's scalability goals are, what guarantees from a storage perspective it gives nor how much value the project is putting on things like interoperability.

Zaqar has quite a set of features that give operators enough flexibility to achieve different scales and/or adapt it to their know-how and very specific needs. Something we've - or at least I have - always said about Zaqar - for better or for worse - is that you can play with its layers as if they were Lego bricks. I still think this is true and it doesn't mean Zaqar is trying to address all the use cases or making everyone happy. We want to give them flexibility to add functionality for additional use cases that aren't supported out of the box.. I know this has lots of implications, I'll dig into it a bit more later.

Zaqar's vision is to provide a cross-cloud interoperable, fully-reliable messaging service at scale that is both, easy and not invasive, for deployers and users.

It goes with no saying that the service (and team) has strived to achieve the above since the very beginning and I believe it does that, modulo bugs/improvements, right now.

Reliability

Zaqar aims to be a fully-reliable service, therefore messages should never be lost under any circumstances except for when the message's expiration time (ttl) is reached - messages will not be around for ever (unless you explicitly request that). As of now, Zaqar's reliability guarantee relies on the storage ability to do so and on the service to be properly configured.

For example, if Zaqar is deployed on top of MongoDB - the current recommended storage for production - you'd likely do it by configuring a replica set or even a sharded cluster so that every message is replicated but if you use a single mongod instance, there's nothing the service can do to guarantee reliability. Well, there actually is, Zaqar could force deployers to configure either a replica set or a sharded cluster and die if they don't - we will likely force deployers.

Scalability

Zaqar's design was thought at scale. Not all storage technologies will be able to perform the same way under massive loads, hence it's really important to choose a storage backend capable of supporting the expected user base.

That said, Zaqar also has some built-in scaling capabilities that aim to make scaling storage technologies easier and push their limits farther away. Zaqar's pools allow users to scale their storage layer by adding new storage clusters to it and balancing queues across them.

For example, if you have a zaqar+mongodb deployment and your mongodb cluster (regardless it is a replica set or a sharded cluster) reaches it's scaling limits, it'd be possible to setup a new mongodb cluster and add it as a pool in Zaqar. Zaqar will then balance queues based on the pools' weight across your storage clusters.

Although the above may sound like a quite naive feature, it is not. The team is aware of the limitations related to pools and the things left to do to make it less so. Let me walk you through some of these things.

One thing that you may have spotted from the above is that pools work in a per-queue basis, which means there's no way to split queues across several storage clusters. This could be an issue for huge queues and it could make it more difficult to keep pools load balanced. Nonetheless, I still think it makes sense to keep it this way and here's why.

By balancing on queues and not messages, we're leaving the work of replicating and balancing messages to the technologies that have been doing it for years. This falls perfectly into Zaqar's will of relying as much as possible on the storage technology without re-inventing the wheel (nothing bad about the later, though). Though, I'd like to go a bit further than just "the service wants to rely on existing technologies".

Messages (data) distribution is not an easy task. I had the pleasure (?) to work on the core of these algorithms in the past and thankfully I know enough to want to be away from this while I can. For the sake of the argument, lets assume we add built-in message distribution in Zaqar. The way I think it would work is that we'd require a set of pools to exist so we can distribute messages across them. Then, the storage cluster itself will take care of the messages' replication. What this means is that deployers life would get more complicated since they'll be forced to create several storage clusters even for very basic Zaqar deployments in order to have messages replicated.

Now, to avoid forcing deployers to create several clusters, lets assume we implement message replication within Zaqar as well. This removes the need for deployers to create several clusters since even a single mongod instance - neither a replica set nor a sharded cluster is needed - would work perfectly as a pool since Zaqar would take care of replicating messages. Without getting into the technical details of how much logic we would need to move into Zaqar and the fact that we would be re-inventing things that had already been done elsewhere, I'd like us to ask ourselves why we should depend on external storage technologies if we already have everything needed to balance and replicate data ourselves? Lets not focus on the many tiny details but the overall picture. The service would be doing most of what's needed so why wouldn't we add the missing part and stop relying on external technologies?

All the above is to say that I'd rather spend time working on a swift driver - which we've discussed since the Icehouse summit - than working on having per-message balancing capabilities in Zaqar. Swift knows how to do this very well and it'd make perfectly sense to have zaqar on top of 1 swift pool and just scale that one. I'm not saying mongodb is not good for this job, although we (Zaqar team) should work on documenting better how to use a sharded mongodb cluster with Zaqar.

In other words, Zaqar's scaling focus most be balanced between the API, the guarantees it provides and the storage technology. I believe most of the focus should be invested in the later. The more pools you add, the more resources you'll need and the more complicated your deployment becomes.

There are definitely some issues related to balancing queues - a.k.a buckets, containers, toy's boxes, drawers, etc - and there's a very good reason why swift doesn't do it for containers. One of the things I'd like to see improved is the balancing algorithm Zaqar uses. As of now, it has a very naive and simple algorithm based on weights. The thing I like about this algorithm is that it gives the deployer enough control over the available clusters and the thing I don't like is that it gives the deployer enough control over the available clusters ;). I'd like to also have an algorithm that would make this balancing easier and that doesn't require the deployer to do anything besides adding new pools.

Again, I think pools are great but we should strive to scale the storage layer as much as possible before adding new pools.

Interoperability

Probably hard to believe but I think this is the most difficult task we have had and we will ever have. The project aims to preserve interoperability across clouds and to be able to do so, the features exposed through the API must be guaranteed to work on every cloud regardless of the storage technologies. As much as I'd like this to be true and possible, I think it's not and I also think this applies to every OpenStack service.

We cannot force deployers to deploy Zaqar in a way it'll preserve interoperability across clouds. Deployers are free to configure Zaqar (and any service) as they wish and install whatever driver they want (even non-official ones). If a deployer configures Zaqar on top of a single mongod instance or simply changes the write concern, Zaqar won't be reliable and message could be lost if the node goes down, hence the guarantee will broken.

In addition to the above, optional features, third-party drivers and custom settings - smaller maximum message size, for example - are neither part of this guarantee nor the team can do anything about them.

What we can do, though, is to make sure the features exposed through the API are supported by all the drivers we maintain, work on a set of deployment scenarios that would guarantee interoperability across clouds and make sure the default values of our configuration options are sane enough not to require any deployment to change them.

I'm sure there's a lot more to interoperability than what I'm stating here. What I want to get to is that we strive to make it easier for the service and deployers to preserve interoperability but I believe it cannot be guaranteed at 100%

As you may have noticed, Zaqar has been under a fire storm for the last ~4 weeks, which has been both exciting and stressful - nonetheless, please keep the fire coming.

Many people have many different expectations about Zaqar and it's impossible to make everyone happy so, if you're part of the unhappy group of people (or end up there), I'm sorry. The team has a clear vision of what this service has to provide and a mission to make that happen. I'm sure the service is not perfect and that you don't need to dig deep to find things that should work differently. If you do, please let us know, we're always looking forward to constructive feedback and making the service better.

Messaging is a broader enough field to cover tons of different tones of grey. While Zaqar is not trying to hold them all, it is definitely trying to provide enough to make the service worth it and suffice the use cases it has.

by FlaPer87 at September 23, 2014 09:46 AM

Zaqar's path going forward

Long time since I wrote my last post about Zaqar (ex Marconi) and I thought this one should be a summary of what has happened and what will, probably, happen going forward.

Let me start by sharing where Zaqar is in OpenStack.

At every end of the cycle - ~6 weeks before it ends, to be precise - every incubated project goes through a review process where things like API stability, integration with the OpenStack ecosystem, community etc - full list - are revisited in order to evaluate the project and determine if it's ready to be part of the OpenStack integrated release. Despite Zaqar having met all those requirements, it was not accepted into the integrated release. The story is long and it's not the intent of this post to walk you through it. However, if you're interested in getting more details about what happened exactly please go here: 1st meeting 2nd meeting 3rd meeting 1st thread 2nd thread Review.

One thing to get from the last review process, and definitely keep in mind, is that Zaqar is ready to be used in production environments. Technically speaking it met all the requirements imposed by the TC and as a project it's had a stable API for quite a bit already.

One of the discussions that happened during the last graduation review was related to whether Zaqar is a queuing service or a messaging service. To me, and as Gordon Sim mentioned in this email there's no real difference between those 2 besides the later being a more generic term than the former. This discussion led to other discussions like whether things like get-message-by-id makes sense, whether keeping queuing semantics is necessary or even whether guarantees like FIFO should be kept.

All the above discussions have been interesting but I'd like to take a step back and walk you through a perhaps less technical topic but not less important. It's clear to me that not everyone knows what the project's vision is. So far, we've made clear what Zaqar's API goals are, what kind of service Zaqar is and the use-cases it tries to address but we haven't neither explicitly explained nor documented well-enough what Zaqar's scalability goals are, what guarantees from a storage perspective it gives nor how much value the project is putting on things like interoperability.

Zaqar has quite a set of features that give operators enough flexibility to achieve different scales and/or adapt it to their know-how and very specific needs. Something we've - or at least I have - always said about Zaqar - for better or for worse - is that you can play with its layers as if they were Lego bricks. I still think this is true and it doesn't mean Zaqar is trying to address all the use cases or making everyone happy. We want to give them flexibility to add functionality for additional use cases that aren't supported out of the box.. I know this has lots of implications, I'll dig into it a bit more later.

Zaqar's vision is to provide a cross-cloud interoperable, fully-reliable messaging service at scale that is both, easy and not invasive, for deployers and users.

It goes with no saying that the service (and team) has strived to achieve the above since the very beginning and I believe it does that, modulo bugs/improvements, right now.

Reliability

Zaqar aims to be a fully-reliable service, therefore messages should never be lost under any circumstances except for when the message's expiration time (ttl) is reached - messages will not be around for ever (unless you explicitly request that). As of now, Zaqar's reliability guarantee relies on the storage ability to do so and on the service to be properly configured.

For example, if Zaqar is deployed on top of MongoDB - the current recommended storage for production - you'd likely do it by configuring a replica set or even a sharded cluster so that every message is replicated but if you use a single mongod instance, there's nothing the service can do to guarantee reliability. Well, there actually is, Zaqar could force deployers to configure either a replica set or a sharded cluster and die if they don't - we will likely force deployers.

Scalability

Zaqar's design was thought at scale. Not all storage technologies will be able to perform the same way under massive loads, hence it's really important to choose a storage backend capable of supporting the expected user base.

That said, Zaqar also has some built-in scaling capabilities that aim to make scaling storage technologies easier and push their limits farther away. Zaqar's pools allow users to scale their storage layer by adding new storage clusters to it and balancing queues across them.

For example, if you have a zaqar+mongodb deployment and your mongodb cluster (regardless it is a replica set or a sharded cluster) reaches it's scaling limits, it'd be possible to setup a new mongodb cluster and add it as a pool in Zaqar. Zaqar will then balance queue's based on the pools' weight across your storage clusters.

Although the above may sound like a quite naive feature, it is not. The team is aware of the limitations related to pools and the things left to do to make it less so. Let me walk you through some of these things.

One thing that you may have spotted from the above is that pools work in a per-queue basis, which means there's no way to split queues across several storage clusters. This could be an issue for huge queues and it could make it more difficult to keep pools load balanced. Nonetheless, I still think it makes sense to keep it this way and here's why.

By balancing on queues and not messages, we're leaving the work of replicating and balancing messages to the technologies that have been doing it for years. This falls perfectly into Zaqar's will of relying as much as possible on the storage technology without re-inventing the wheel (nothing bad about the later, though). Though, I'd like to go a bit further than just "the service wants to rely on existing technologies".

Messages (data) distribution is not an easy task. I had the pleasure (?) to work on the core of these algorithms in the past and thankfully I know enough to want to be away from this while I can. For the sake of the argument, lets assume we add built-in message distribution in Zaqar. The way I think it would work is that we'd require a set of pools to exist so we can distribute messages across them. Then, the storage cluster itself will take care of the messages' replication. What this means is that deployers life would get more complicated since they'll be forced to create several storage clusters even for very basic Zaqar deployments in order to have messages replicated.

Now, to avoid forcing deployers to create several clusters, lets assume we implement message replication within Zaqar as well. This removes the need for deployers to create several clusters since even a single mongod instance - neither a replica set nor a sharded cluster is needed - would work perfectly as a pool since Zaqar would take care of replicating messages. Without getting into the technical details of how much logic we would need to move into Zaqar and the fact that we would be re-inventing things that had already been done elsewhere, I'd like us to ask ourselves why we should depend on external storage technologies if we already have everything needed to balance and replicate data ourselves? Lets not focus on the many tiny details but the overall picture. The service would be doing most of what's needed so why wouldn't we add the missing part and stop relying on external technologies?

All the above is to say that I'd rather spend time working on a swift driver - which we've discussed since the Icehouse summit - than working on having per-message balancing capabilities in Zaqar. Swift knows how to do this very well and it'd make perfectly sense to have zaqar on top of 1 swift pool and just scale that one. I'm not saying mongodb is not good for this job, although we (Zaqar team) should work on documenting better how to use a sharded mongodb cluster with Zaqar.

In other words, Zaqar's scaling focus most be balanced between the API, the guarantees it provides and the storage technology. I believe most of the focus should be invested in the later. The more pools you add, the more resources you'll need and the more complicated your deployment becomes.

There are definitely some issues related to balancing queues - a.k.a buckets, containers, toy's boxes, drawers, etc - and there's a very good reason why swift doesn't do it for containers. One of the things I'd like to see improved is the balancing algorithm Zaqar uses. As of now, it has a very naive and simple algorithm based on weights. The thing I like about this algorithm is that it gives the deployer enough control over the available clusters and the thing I don't like is that it gives the deployer enough control over the available clusters ;). I'd like to also have an algorithm that would make this balancing easier and that doesn't require the deployer to do anything besides adding new pools.

Again, I think pools are great but we should strive to scale the storage layer as much as possible before adding new pools.

Interoperability

Probably hard to believe but I think this is the most difficult task we have had and we will ever have. The project aims to preserve interoperability across clouds and to be able to do so, the features exposed through the API must be guaranteed to work on every cloud regardless of the storage technologies. As much as I'd like this to be true and possible, I think it's not and I also think this applies to every OpenStack service.

We cannot force deployers to deploy Zaqar in a way it'll preserve interoperability across clouds. Deployers are free to configure Zaqar (and any service) as they wish and install whatever driver they want (even non-official ones). If a deployer configures Zaqar on top of a single mongod instance or simply changes the write concern, Zaqar won't be reliable and message could be lost if the node goes down, hence the guarantee will broken.

In addition to the above, optional features, third-party drivers and custom settings - smaller maximum message size, for example - are neither part of this guarantee nor the team can do anything about them.

What we can do, though, is to make sure the features exposed through the API are supported by all the drivers we maintain, work on a set of deployment scenarios that would guarantee interoperability across clouds and make sure the default values of our configuration options are sane enough not to require any deployment to change them.

I'm sure there's a lot more to interoperability than what I'm stating here. What I want to get to is that we strive to make it easier for the service and deployers to preserve interoperability but I believe it cannot be guaranteed at 100%

As you may have noticed, Zaqar has been under a fire storm for the last ~4 weeks, which has been both exciting and stressful - nonetheless, please keep the fire coming.

Many people have many different expectations about Zaqar and it's impossible to make everyone happy so, if you're part of the unhappy group of people (or end up there), I'm sorry. The team has a clear vision of what this service has to provide and a mission to make that happen. I'm sure the service is not perfect and that you don't need to dig deep to find things that should work differently. If you do, please let us know, we're always looking forward to constructive feedback and making the service better.

Messaging is a broader enough field to cover tons of different tones of grey. While Zaqar is not trying to hold them all, it is definitely trying to provide enough to make the service worth it and suffice the use cases it has.

by FlaPer87 at September 23, 2014 09:43 AM

September 22, 2014

Solinea

Join Solinea at Cloud Connect @ Interop

ccnycJoin Solinea at Interop / Cloud Connect this month in New York City, where the team will be hosting the Introduction to OpenStack: Enterprise Boot Camp. The OpenStack Enterprise Boot Camp provides an opportunity for cloud architects, IT managers and business leaders to gain a working understanding of OpenStack and how to achieve business agility, performance and scale, and cost-savings within an existing enterprise environment.  This introduction will cover topics such as enterprise readiness for OpenStack, how to choose the best cloud for your applications and real world examples on how companies are taking advantage of OpenStack today. In addition, it will also provide an overview of the OpenStack ecosystem and how you can leverage this growing group of companies to make sure your deployments are successful.

by Seth Fox (seth@solinea.com) at September 22, 2014 08:00 PM

Tesora Corp

OpenStack's Next Move Is To Remove Complexity

46318283_2f4b0a6f0d_o.jpgOpenStack has been steadily gaining in popularity in the enterprise, but as it does, it's hard to paper over one large limitation: it's highly complex and requires a high level of technical expertise to implement well.

As more companies companies want to jump on the OpenStack bandwagon, they are seeing this complexity and many simply don't have the resources or expertise to put to bear on an OpenStack project --and they want help.

The large companies that have adopted OpenStack, particularly Red Hat, HP and IBM see this too and they are companies that typically introduce service offerings to help ease the transition.

This isn't atypical where open source projects are concerned.

Most projects that get popular follow a predictable arc. Early adopters use the raw package and wrestle with it to work out the early kinks. With help from local group meetings, online forums and larger conferences, the first users figure out ways to build the first generation projects and make them work.

As a project like OpenStack reaches a certain critical mass and begins to mature, more companies come on board that don't want to go through those struggles. They may lack technical staffing expertise or the just want to get up and running more quickly.

That's when new simplification products from the big companies come into play. They begin to offer products and services that simplify the complex and put a project like OpenStack within reach of a broader audience than the early adopter crowd.

The second stage requires products that let companies understand these systems more easily without an army of technical talent. They need consultants and they need plug and play appliances and all evidence suggests that's what's coming.

In fact, HP introduced a series of services recently designed specifically to address this problem from design and deployment through support and training, all designed to make it easier for organizations to explore, implement and support OpenStack projects. You could argue too that HP's recent purchase of Eucalyptus was about the startup's ability to create appliances. If HP continues to build out its OpenStack business, then having Eucaplyptus's appliance design experience in the fold could help them build these appliances that provide "OpenStack in a box" capability that many companies who want to be shielded from the project's complexity could be looking for.

Just last week AMD and Ubuntu came out with a product called OpenStack in a rack and Red Hat recently announced an appliance for testing OpenStack for those organizations who just want to try it out, but don't want to get their hands dirty.

All of this suggests that vendors recognize the market opportunity and are looking for ways to deliver a kinder, gentler OpenStack to customers who don't want to dig around in the technical bits to make it work. They just want the advantages and they want someone who is going to provide support for them when things go wrong or their requirements change.

OpenStack has been growing steadily, but if it wants to really get to the next level, it is going to require tools to help the next layer of customers come on board. Look for a new generation of helper products and services to keep expanding to help them achieve that.

by 693 at September 22, 2014 03:40 PM

Opensource.com

Dealing with OpenStack's growth, improving documentation, and more

Interested in keeping track of what's happening in the open source cloud? Opensource.com is your source for what's happening right now in OpenStack, the open source cloud infrastructure project.

by Jason Baker at September 22, 2014 03:00 PM

Maish Saidel-Keesing

My Toolbox is Becoming Heavy

I would like to add one or two more points points to my previous post - An Open Letter to the OpenStack Foundation.

  1. I used Ceilometer as an example, and only as an example. I am more than sure that there are perfectly valid reasons to have chosen MongoDB instead of MySQL. I have no doubt. But doing so this still introduces more complexity.
  2. Paul Richards left a comment – and because of his example – I think this just made thoughts even clearer.

    "The point is to use the right tool for the job. Don't use pliers when you need to use a wrench".

    I completely agree with that. I “stole” his example and used it to further emphasize my point.

    Of course every tool has to fit the right job, but to steal your analogy (forgive me), each group thinks that their tool is the right one. And over time - instead of walking around with only a pliers and a wrench you now need a big toolbox with a hammer, a saw, 15 different screwdriver bits, a cutters, duct tape, wire, a wrench, a pliers and so on and so on.

    To continue the analogy - I would have like to see the TC either change the bolt - whether now or in the future - that it will become acceptable for both tasks with one tool. Or alternatively create a tool that can be used both as a wrench and as a pliers.

    That is the job of the TC. But I personally feel that since the work being done on the overall architecture, a holistic OpenStack Product architecture, is lacking - here is where the biggest potential failure could occur.

    I already see it breaking apart - with different HA models, different scaling models for the different components. And it is only going to get worse.

ToolboxMy toolbox becometh heavy.

by Maish Saidel-Keesing (noreply@blogger.com) at September 22, 2014 10:30 AM

September 19, 2014

OpenStack Blog

OpenStack Community Weekly Newsletter (Sep 12 – 19)

The Kilo Design Summit in Paris

In less than two months the OpenStack development community will gather in Paris to discuss the details of the Kilo development cycle. It starts after the keynotes on the Tuesday of the summit week, and ends at the end of the day on the Friday. We decided a number of changes in the Design Summit organization in order to make it an even more productive time for all of us.

Reports from Previous Events

The Road To Paris 2014 – Deadlines and Resources

During the Paris Summit there will be a working session for the Women of OpenStack to frame up more defined goals and line out a blueprint for the group moving forward. We encourage all women in the community to complete this very short surveyto provide input for the group.

Relevant Conversations

Tips ‘n Tricks

Security Advisories and Notices

Upcoming Events

Other News

Got Answers?

Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:

Welcome New Reviewers, Developers and Core Reviewers

Welcome Nejc Saje to ceilometer-core and Radoslav to oslo-vmware core team and StevenK to core tripleo core team

m-k-k Rafael Rivero
Loa Billy Olsen
Dave McCowan Zoltán Lajos Kis
Zhai, Edwin Yogesh
Syed Ismail Faizan Barmawer Rajaneesh Singh
Neill Cox Barnaby Court
Satoru Moriya Ari
Jamie Finnigan Gary Hessler
Dan Sneddon Chardon Gerome
Brian Tully
woody
Martin André

OpenStack Reactions

rolling-back-a-change

Rolling back a change

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.

by Stefano Maffulli at September 19, 2014 11:12 PM

Ed Leafe

Simplifying OpenStack

Recently I’ve returned to working on the OpenStack code base after a couple of years of working on related projects, and the sheer scope of the changes to the code, both in size and structure, is a bit overwhelming. I’ve also had to catch up with the current issues being discussed among the community, as a project that is growing the way OpenStack is will always have pain points. One such discussion that caught my attention concerns the very definition of what OpenStack is. The discussion not only addresses some of the experiences I’ve had returning to the world of OpenStack development, but it also feels like a continuation of the discussions we had when we were first shaping the project 4 years ago.

Sean Dague wrote an interesting take on this, envisioning OpenStack as a set of layers. The lowest layers provided the basic compute infrastructure, and the higher layers either built on this, or added additional capabilities. While I can see the basis for this division, it struck me as somewhat arbitrary; I mean, are Heat and Trove really that similar in either purpose or architecture?

Yesterday I read Monty Taylor’s blog post on this topic, and I think he has much more accurately captured the relationship between the various parts of OpenStack. His post is much more far-reaching than simply describing OpenStack; it’s really more concerned with how to help OpenStack move forward, and uses these relationships to make his case.

I think that working with the notion that there is a fundamental base for OpenStack (what Monty and Sean both refer to as ‘Layer #1‘), and that everything else is an add-on to this base, will have several positive results. First, it simplifies the internals of these projects. As Monty points out, “nova shouldn’t need a config file option pointing to where glance is, it should just be able to ask the keystone service catalog”. In other words, these Layer #1 projects can assume that they are all present, and don’t have to add needless complexity to handle these relationships. Glance and Keystone have to be there, or Nova can’t work – period.

Second, it streamlines the testing process considerably. The only tests for changes to any of these Layer #1 projects that need to be run are those for their internal workings, and those for their interfaces. This smaller, more manageable gate should relieve (but not eliminate) some of the testing bottlenecks OpenStack experiences today.

Speaking of interfaces, this is the third, and in my opinion, the most significant benefit of this concept: it forces the interfaces between the various projects to be defined clearly, and makes testing any potential change to these interfaces much cleaner. Let’s take the example of Trove: it started as a separate database-as-a-service built on top of Nova, but now is being consumed internally to handle Nova’s database needs. With the current “everything is OpenStack” approach, the lines between Nova and Trove might start to blur, and before long Trove and Nova would become too tightly bound to separate. By keeping the interface between the two clean and separate, it allows for the possibility that another DBaaS project may come along that performs better for Nova’s needs, and can be adopted without having to rip out any hard assumptions about Trove. Similarly, other DBaaS could be developed that are optimized for other use cases, and these can test their interfaces to assure that they can also be implemented as a drop-in replacement for Trove.

Monty identified yet another benefit: there will no longer be a “race” for teams to get officially designated as part of OpenStack, as this designation would go away. Instead, there would be a known set of interfaces that a project would have to support, and if there is more than one group with an idea for implementing a particular need, they can each develop their code without having to first get “blessed” as somehow the “official” OpenStack solution for this need. Developing to a known interface will allow the community to test these different solutions much more easily, and allow a superior solution arise, instead of having to settle for the solution that got there first.

Finally, I see a side benefit to this kind of simplicity of structure. Someone coming to OpenStack for the first time, the sheer number of projects is daunting. Never mind having to learn all the names and what each project does; it’s the feeling that OpenStack is too big to wrap your brain around that can potentially discourage new developers. A clear separation between the heart of OpenStack and the various peripheral projects would eliminate that confusion.

I’m greatly encouraged by these discussions, as it helps clarify the long-term direction of OpenStack. And I’m extremely happy to be part of it all once more.

by ed at September 19, 2014 02:54 PM

Mirantis

Inaugural OpenStack Silicon Valley Conference Draws 590 Attendees from Open Cloud Community

MOUNTAIN VIEW, CA – Sept. 19, 2014 – Mirantis, the pure-play OpenStack company, hosted the inaugural OpenStack Silicon Valley at the Computer History Museum in Mountain View, CA on September 16, 2014. More than 590 attendees gathered at the sold-out event, including more than a dozen analysts and journalists from Gartner, IDC, 451 Research, SiliconANGLE, eWeek, TechTarget, Web Host Industry Review, The New Stack, and GigaOm.

An A-list roster of speakers shared insights with the OpenStack community, including:

  • Eucalyptus CEO (soon to be senior vice president and general manager of HP’s cloud business) Marten Mickos, who spoke about his goal of “total victory for open source.”

  • HP EVP and CTO Martin Fink, who reiterated Hewlett-Packard’s commitment to OpenStack, and discussed why HP bought Eucalyptus.

  • OpenStack Foundation Executive Director Jonathan Bryce, who stated that “nothing kills innovation like having to submit a ticket,” meaning that innovation needs to happen faster if vendors want to maintain their customer base.

  • VMware CTO of Networking Martin Casado, who analyzed what was meant by “policy” and what engineers need to do in order to leverage technology to implement the agendas of non-technical professionals.

  • Cloudscaling CEO and Founder Randy Bias, who attacked the notion that OpenStack needs a “benevolent dictator” like Linux and emphasised the need for an OpenStack product strategy.

  • Mirantis CEO Adrian Ionel, who explored what developers really care about: a focus on APIs, interoperability and central planning that is advisory, not compulsory.

OpenStack Silicon Valley was sponsored by companies across the OpenStack ecosystem: A10 Networks, Blue Box Cloud, Blue Chip Tek, Inc., Brocade Communications Systems, Cisco Systems, Inc., Cloudscaling Group, Inc., DreamHost, GigaSpaces Technologies, Inc., Hewlett-Packard, Juniper Networks, Nebula, Inc., Oracle Corporation, Piston Cloud Computing, PLUMgrid, Tesora, Scality, SolidFire, StackVelocity, SwiftStack, Ubuntu and VMware, Inc.

“A whole series of organizations, many of whom are ordinarily competitors, came together to sponsor, discuss, and promote OpenStack,” said Mirantis CMO and co-founder, Boris Renski. “The event’s success is thanks to everyone who attended, from our superb speakers who took time out to share their insights, to our sponsors, to first-time attendees learning the ropes of the OpenStack ecosystem.”

About Mirantis
Mirantis is the world’s leading OpenStack company. Mirantis delivers all the software, services, training and support needed for running OpenStack. More customers rely on Mirantis than any other company to get to production deployment of OpenStack at scale. Among the top five companies worldwide in contributing open source software to OpenStack, Mirantis has helped build and deploy some of the largest OpenStack clouds at companies such as Cisco, WebEx, Comcast, Symantec, Ericsson, Expedia, Samsung, NASA, NTT Docomo, Workday, and PayPal. Mirantis is venture-backed by Ericsson, Intel, Red Hat, SAP Ventures and WestSummit Capital. For more information, visit www.mirantis.com or follow us on Twitter at @mirantisit.

Contact Information:

Yotam Levy FLAK 42
650.319.8604 ext. 102
yotam@flak42.com

The post Inaugural OpenStack Silicon Valley Conference Draws 590 Attendees from Open Cloud Community appeared first on Mirantis | The #1 Pure Play OpenStack Company.

by Sarah Bennett at September 19, 2014 01:00 PM

Opensource.com

Workload deployment tools for OpenStack

The second in a three part series, this article looks at open source tools for deploying workloads onto OpenStack and how they differ from one another.

by Dmitri Zimine at September 19, 2014 09:00 AM

Rafael Knuth

Recording & Slides: How is IBM using OpenStack?

In yesterday`s OpenStack Online Meetup Emily Hugenbruch explained how IBM is using OpenStack...

September 19, 2014 08:50 AM

Stefano Maffulli

Improving Documentation for new OpenStack Contributors

I think we’re starting to see too much friction and pain from contributors to OpenStack plugins, drivers, extensions: a lot is going on and joining the community feels like boarding a bullet train while it’s running at full speed. We’ve been doing a good job pulling people in the OpenStack community and educate them with our tools, processes especially for contributors to the Compute, Storage, Networking pieces of OpenStack; there are margins to improve life for “casual” contributors and newcomers in general.

The main problem I think is that we’ve been treating all developers like they all have the same amount of dedication to the collaboration effort. We’ve been asking every person contributing to OpenStack to act the same way, whether they were fixing a small bug in Keystone or refactoring Neutron’s code: same gerrit review workflow, same process for blueprints/specs. We assumed always that anybody at any given time had the same level of knowledge of deadlines and recent changes to the processes. We are requiring people with radically different objectives and set of incentives to know and do the same things. I think this is starting to become too much of a problem for the community. We are already having conversations about this (split drivers, Neutron incubator, refocus summit, modify the legal requirements) and will continue discussing in Paris.

The one thing that we should start improving immediately is the documentation for new contributors. New contributors have lots of resources available like the Welcome Guide, docs.openstack.org/developer, lots of wiki pages of varying degree of correctness and quality, tips and tricks on blog posts, upcoming video series, IRC support and Upstream Training. Based on what I hear from some, they struggle because these are in different places and owned by different people. A place where this content is shown in a more coherent way would be a great improvement.

There are two efforts to improve various pieces of documentation: the Documentation program wants to redesign the Docs portal, and a new portal is being designed for developers of applications based on OpenStack. The Documentation program is not responsible for developers’ content on the Docs portal, it simply hosts the materials produced directly by the programs. While we wait for a redesign of the Documentation portal, I think we can start by fixing the wiki pages. With the help of a taxonomy produced by volunteer Katherine Cranford and Foundation’s staff Shari Mahrdt, we’ll give a bit more structure to the OpenStack wiki. Stay tuned for more details.

 


© stefano for ][ stefano maffulli, 2014. | Permalink | No comment | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

by stefano at September 19, 2014 12:03 AM

September 18, 2014

Red Hat Stack

Announcing Red Hat Enterprise Virtualization 3.5 Beta

Today, we are excited to announce the availability of Red Hat Enterprise Virtualization 3.5 Beta to existing Red Hat Enterprise Virtualization customers. The Beta release allows our customers to easily manage and automate many virtualization tasks while providing an on-ramp to accommodate cloud enabled workloads based on OpenStack. Red Hat Enterprise Virtualization 3.5 Beta provides new features across compute, storage, network, and infrastructure.

One key feature to highlight is the full integration with OpenStack Glance and Neutron services. This feature was previously in tech preview. The strong integration between Red Hat Enterprise Virtualization and OpenStack enables customers to eliminate silos and scale up to meet business demands.

Red Hat Enterprise Virtualization 3.5 Beta is available to all existing customers with active Red Hat Enterprise Virtualization subscriptions today. Please view the 3.5 Beta Installation Guide here for details on how to start testing the beta release.

Please note that RHEV 3.5 Beta 1 will not support the use of the RHEV-H Hypervisor and will only support the use of a RHEL Hypervisor Host.  We apologize for this delay, and plan on the RHEV-H Hypervisor to be available in the RHEV 3.5 Beta 2 refresh.

Also note that there was a last second issue identified with the dwh component that prevents its installation in RHEV 3.5 Beta 1.  This will be resolved in the RHEV 3.5 Beta 2 refresh.

by rtona at September 18, 2014 06:57 PM