csuttles (⌐■_■)

Memento Mori

Learn about Keystone to Keystone federation and see it work with Horizon for Ocata Elvin Tubillara Nithya Renganathan https://www.openstack.org/videos/boston-2017/learn-about-keystone-to-keystone-federation-and-see-it-work-with-horizon-for-ocata The crux of this lightning talk was: Keystone instance "A" is source of identity Keystone instance "B" uses Keystone "A" as source ov identity via Shibboleth/SAML2.0 Mappings are created for B->A. This only gets you identity, not ssh-keys or other Keystone components For this to be successful, users must fully qualify their names, like user@VagrantServiceProvider

Home of Open {Composable} Infrastructure Mark Collier https://www.openstack.org/videos/boston-2017/home-of-open-composable-infrastructure Mark talked about hacking on Apple IIs and cutting class to play Doom, and how computing has evolved to become the foundation for important human achievements like science, industry, going to mars, or curing disease. He talked about the using open source first for solving technical problems, and the importance of AI, and machine learning. Some of the open source platforms he talked about included:

Consuming Multiple OpenStack Clouds with Ease Monty Taylor https://www.openstack.org/videos/boston-2017/consuming-multiple-openstack-clouds-with-ease Shade - what is it? Task oriented lib Multi-Cloud Scalable (used on 20k servers a day in managing OpenStack CI) Logic design is borrowed heavily from nodepool lib in Python and Ansible https://github.com/openstack-infra/shade #openstack-shade on freenode Side note: presentation was made using https://pypi.python.org/pypi/presentty We got a walkthrough of the module, and a demo where a server was created and destroyed in 3 different clouds, located in 3 different providers (with different credentials)

GEIX / GE Healthcare They shared their success stories with OpenStack, which included reducing the time required for some medical imaging from over 1 day to minutes. This was in partnership with a research endeavor they sponsor. Taking OpenStack to the Network Edge (Verizon) Verizon previewed their OpenStack in a box CPE, which was 1U, LTE capable with four antennas, and runs OpenStack in containers. It's part of their globally, massively distributed OpenStack footprint.

Upstream Institute Sunday, I attended this session, and met some great people. I sat with two Swift core contributors, two Cinder contributors, and a Manilla contributor who also previously contributed to Horizon and Trove. The class was an intro to contributing to OpenStack, so I was lucky to end up at a table full of seasoned folks. I made connections with almost everyone at the table, and I really enjoyed speaking with them and learning from them.

As part of our efforts to improve the resilience of OpenStack within sites, we are moving to a multi controller architecture. I decided to tackle the underlying, stateful infrastructure services first. The first of those I looked into was RabbitMQ. RabbitMQ supports clustering, and HA queues, as well as durable queues (queues that persist to disk). The setup seems fairly simple, but unfortunately many things still assume IP means IPv4, and that's exactly where this got interesting.

In Mitaka release, I worked with our storage team and deployed a NetApp Cinder backend, using Fibre Channel connectivity from the nodes running cinder-volume. When I upgraded to Newton, we started seeing errors in the cinder-volume logs that seemed to match this bug: NetApp: Failed to get info for aggregate Unfortunately, at that time, there was not a fix available, we lost my POC for this project on the storage team, and the leaders in the org wanted to explore going a different way, so we dropped the cinder backend, instead of submitting a patch or finding a resolution.

We added availability zones to our deployment for a few reasons. Fault domain isolation The foremost of these was to isolate fault domains within our environment. Spreading workload across availability zones allows us to ensure that the applications and services provided by the OpenStack workload are resilient. Influencing placement Availability zones afford us more granular control of scheduling, without modifying configs or changing the default scheduler hints or filters. This allows us to be specific enough about placement to steer things in an intelligent way, while avoiding the burden of placing everything manually.

In my last post, I detailed a few things I experienced moving the Ocata release of OpenStack to an IPv6 only environment. While the major hurdles are complete, there are still more things to consider Image Automation We build images using Jenkins and Packer, and push those images into glance, which stores them in a Swift backend. That's all still going smooth, but where we ran into trouble is the automation of configuration.

Since I took the lead on the OpenStack deployment in my workplace, IPv6 has been a major goal of our deployment. IPv6 is a first class citizen in our infrastructure, and the other environments that OpenStack coexists with are already running IPv6 only. This made getting OpenStack to run IPv6 only a major milestone, which was finally accomplished during our move to Ocata release. Standards and SSL Termination While running client workload with IPv4 or dual stack is acceptable, or even required in some cases (vendor packaged VMs are notoriously guilty here), the standard for deploying infrastructure is high.