Dr. Jonathan Appavoo was kind enough to invite me to be a guest lecturer in his distributed systems class at Boston University. The students proved a list of questions, and I only got a chance to address a handful of them during the class. So, I’ll try to address the rest here.

Page 1 of 1 So far (I’ll update this line as I post the others.)

When do tokens expire? If they don’t expire, isn’t it potentially dangerous since attackers can use old tokens to gain access to privileged information?
Tokens have a set expiry. The default was originally set to be 12 hours. We shortened that to 1 hour a couple years back, but it turns out that some workloads use a token all the way through, and those workload last longer than 1 hour. Those deployments either have lengthened the life of the token in the configuration or had users explicitly request tokens that last longer than an hour.

Can users share roles with in the same project?
Yes, and this is the norm. A role assignment is a many to many to many association between users (or groups of users), projects, and roles. This means:

• One user may have multiple roles on the same project
• One user may have the same role on multiple projects
• Multiple users may have the same role on a project
• Any mix of the above

It’s interesting that one of the key components is a standardized GUI (Horizon). Wouldn’t it be more useful for there to be a handful of acceptable GUIs tailored to the service a particular set of OpenStack instances is providing?

This is the standardized GUI as you point out. While many companies have deployed OpenStack with custom GUIs, this one is the one that is designed to be the most generally applicable. Each user gets a service catalog along with their tokens, and the Horizon UI can use this to determine what services the user can see, and customize the UI displayed accordingly. So, from that perspective, the UI is tailored to the user.

The individual project teams are not compose of UI or UX folks. You really don’t want us designing UI. As soon as you realize the tough problem is getting a consistent look, feel, set of rules, and all the things that keep users from running away screaming, you realize that it really is its own effort and project.

That said, I did propose a few years back that the Keystone project should be able to render to HTML, and not just JSON (and XML). This would be the start of a progressive enhancement approach that would also make the Keystone team aware of the gaps in the coverage of the UI: its really easy to see when you click through. But, again, this was for test-ability, completeness, and rapid implementation of a UI for new features, not the rich user experience that is the end product. It would still be the source for a follow on UX effort.

Since that time, the Horizon team has embraced a single-page-app effort based on a proxy (to avoid CORS issues) to all of the endpoints. The proxy converts the URLs in the JSON requests and responses to the proxy, but otherwise lets things pass unchanged. I would love to see HTML rendering as an option on this proxy.

Can You elaborate on some examples of OpenStack being used by companies on a large scale?

Here is the official list. If you click through the Case studies, some of them have numbers.

A question about the philosophy behind open source. Do the  problems that arise in distributed systems lend themselves well to an open source approach? Or does Brooks’s Law apply?

Brooks law states: “adding manpower to a late software project makes it later.”  Open source projects are not immune to Brook’s Law.  OpenStack is not driven by any one company, and it has a “release each 6 months” rule that means that if a feature is not going to make a release, it will have another chance six months later.  We have not slipped a release since I’ve been on the project, and I don’t think they did before.

The Keystone team is particularly cautious. New features happen, but they are well debated, beat on, and often deferred a release or more.  Getting code into Keystone is a serious undertaking, with lots of back and forth for even small changes, and some big changes have gone through 70+ revisions before getting merged.  I have a page and a half of links to code that I have submitted and later abandoned.

Adding more people to a project under OpenStack (like Keystone) can’t happen without the approval of the developers.  I mean, anyone can submit and review code, but to be accepted as a core requires a vote of confidence from the existing cores, and that vote won;’t take place if you’ve not already proved yourself.  So the worst that could happen is that one company goes commit happy and gets a bunch of people to try to submit patches, and we would ignore them. It hasn’t happened yet.

Does the public source code make authentication a much more difficult project for OpenStack than it is for a close source Identity-as-a-Service?

So, the arguments why Open Source is good for security is well established, and I won’t repeat them here.  To me, there are Open Source projects, and then there is the Open Source development model.  The first means that the code3 is free software, you can contribute, etc.  But it means that the project might be run by one person or company.  The Open Source development model is more distributed by default.  It means that no one person can ram through changes.  Even the project technical leaders can;t get away with approving code without at least another core also approving.  Getting anything done is difficult.  So, from that perspective, yes.  But there is lot of benefit to offset it:  we get a wider array of inputs, and we get public discussion of features and bugs.  We get contributions from people that are interested in solving their own problems, and, in doing so, solve ours.

Why can we not force or why has there not been more standardization for Identity Providers(IdPs) in a  federation?

Adoption of Federated protocols has been happening, slow but steady.  SAML from “oh that’s neat” to “we have to have that.”  IN my time on this project.  SAML is apretty good standard, and many of the IdPs are implementing it.  There is a little wiggle room in the standard, as my coworker who is working on the client protocol (ECP) can tell you, but the more implementations we see, the more we can iron out the details.  So, I think at least from SAML, we do have a good degree of standardization.

The other protocols are also picking up steam, and I think will play out similarly to SAML.  I suspect the OpenID connect will end up just as well standardized in implementation as SAML is starting to be.  The process is really iterative, and you don;t know the issues you are going to have to deal with until you find them in a deployment.

What makes OpenStack better than other Cloud Computing services?

Short answer: I don’t know.

Too Long answer with a lot of conjecture:  I think that the relative strength of OpenStack depends on which of the other services you compare it to.

Amazon’s are more mature, so there the OpenStack benefit is Open Source, and that you can actually implement it on premise, not just have it  hosted for you.  Control of Hardware is a still a big deal.  I think the Open Source aspect really helped OpenStack compete with vCloud as well.

I think that the open source development model for the Cloud mirrors the success of the Linux Kernel.  The majority of the activity on the Kernel is device drivers.  In OpenStack, there is a real push by vendors to support their devices.  In a proprietary solution, a hardware vendor is dependent on working with that proprietary software vendor to get their device supported. In Open Stack, any device manufacturer that wants to be part of Cinder, Nova, or Neutron can get the code and make it work.

This means that even the big vendors get interested.  The software becomes a marketplace of sorts, and if you can’t inter-operate, you miss out on potential sales.  Thus, we have Cisco interested in Neutron and VMware interested in Nova where it might have initially appeared against their interested to have that competition.

I think part of its success was due to the choice of the Python programming language.  Its a language that System administrators don’t tend to react to negatively like they do with Java.  I pick on Java because it was the language used for Eucalyptus.  I personally like working in Java, but I can really see the value in Python for OpenStack.  The fact that source code is essentially shipped by default overcomes the Apache license potential for a closing off code: end users can see what is actually running on their systems. System administrators for Linux systems are likely to already have some familiarity with Python.

I think the micro project approach has also allowed OpenStack to scale.  It lets people interested in identity focus on identity, and block storage people get to focus on block storage.  The result has been an explosion of interest in contributing.

I think OpenStack got lucky with timing:  the world realized it needed a cloud management solution when OpenStack got mature enough to start filing that role.