On 07/25/2011 07:17 AM, Simon Harris wrote:
Some ranting and raving as a VERY newbie guy on the project:
On 25/07/2011, at 4:44 AM, Hugh Brock wrote:
> Speaking of the whole Conductor/Orchestrator split. Mark and I got
> very excited about this because it seemed like there would be room for
> two smaller independent OSS projects there rather than one big hairy
> one. I've heard privately from various people however that they
> thought that split would leave Conductor as a not-all-that-interesting
> piece by itself, concerned only with cloud resource allocation and
> permissions (and some level of display of various things).
Not quite sure what "not-all-that-interest" means. Presumably it's useful
in which case I don't really get the rationale for NOT splitting it. If OTOH splitting
it makes it less useful/maintainable then I can understand. I get bits of software being
less interesting than others but ultimately the utility trumps developer enthusiasm,
surely?
> Conductor features:
FWIW, I tend to think of things in terms of our goals. What are they, why have we not yet
met them, and what is the bare minimum needed to achieve them. As I see it we have
several, somewhat overlapping, goals:
* Whatever stated or unstated goals Red Hat has internally;
* Generating developer interest;
* Building a wider community beyond developers; and ultimately
* End user satisfaction
Assuming you agree with the premise (of course feel free to disagree), as a relative new
comer to the project I'm still trying to work out how what we have built and what we
are planning on building gives us a shortest path to addressing these. I can't help
but feel some of the proposed features are:
* Interesting irrespective of necessity for success,
* Ideal but not necessary for success,
* Necessary but not sufficient for success
Ideally I would LOVE to see a single user of our software in the wild or a developer at
an organisation able to just download the stack and start hacking away even if that means
not building the grand vision in the short term. Anyway, I digress...
> * Authorization. We have a fair amount of authorization checking in
> place, but no way to actually set who can do what. Given that a
> central Conductor feature is the ability to control access to cloud
> resources, this seems like an important feature.
Is it? What's the worst thing that would happen if a user had to, as an example, edit
a text file in order to specify permissions. Whats the worst case if permissions were
specified more coarsely for now even if the existing infrastructure is finer grained? If I
put on my potential customer hat, the promise of fine-grained permissions management UI is
great, but having something in my hand that works reasonably well right now would be
better :/
> * Identity and encryption. Authorization doesn't do a lot of good if
> anyone can bumble along and impersonate anyone else, so it would be
> pretty nice to have at least a workaday identity and encryption
> setup.
Is it necessary though? If the guy who is going to set this thing up is a sysadmin does
he really need to authorize himself?
> Conversations with potential users have suggested the
Now I'm liking what I'm hearing...
> following minimum features, feel free to suggest your own:
>
> * Conductor will authenticate against an LDAP server. Since most
> LDAP servers in the real world are Windows Active Directory, we
> should probably include AD in the set of servers we test against.
Agreed. In my experience most potential customers will want LDAP or OAuth.
> * Fall back to local user data store, maybe? You can imagine needing
> a local admin user that isn't in LDAP, for example
Perhaps, but does this really need a UI?
> * Be able to proxy identity when talking to other things that need
> to know it. Checking identity when saving things to/retrieving
> things from Image Warehouse is the main requirement for this. I
> think it's getting a GSSAPI library soon which should help. We
> will also probably need this for Katello, when we get to talking
> to it. FWIW Katello is currently using two-legged OAuth for this,
> so I would think this would be the primary candidate for us too.
Above my current level of understanding of the stack but again, it *sounds* very
technical and not couched in terms of the outcome for a potential customer. What would
they be able to/not be able to do if this didn't happen?
> * A way to encrypt the traffic between Conductor, Deltacloud API,
> Warehouse, and Katello. The obvious solution for this is ssl certs
> that are created and signed by the installer, with some way to
> update/revoke them.
What's the worst thing that would happen without this? It sounds like something that
would be really nice to have but it doesn't sound necessary for success (as loosely
defined above)
<rant>
Many projects in the past have taken the path of "let us care less about
this security stuff, we will deal with it later." Guess what... Such
approach leads to the situations when security is bolted on and as a
result does not work well. Projects get abandoned and forgotten. It
usually requires either a lot of effort to re-factor the code to make
things right and few have power, cycles and will to go this path. Some
do and survive but incur the cost.
IMO the right thing is to decide on all this authentication,
authorization, permissions, encryption etc. in advance. Build a minimal
part and add as you go. As the component layout changes these plans
should be re-reviewed, validated and adjusted. We should get into habit
of doing it.
But at the moment I do not see a good consistent plan across the board
in the first place. Every component tries to solve the problems
differently and without joint thinking of the ultimate result. It seems
we are building patchy blanket here. I do not think customers will
appreciate it.
</rant>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/