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)
* Admin UX work
* We need to give the pool, pool family, and provider management
screens the same loving treatment we have given the instance
management screens.
Really? Why? I would have thought that a user of the software is hardly going to worry
about a few colours here and there if they had to make the choice between, I want it to
work and I want it to look pretty. Yes, pretty is stupidly important in some cases. Is
this really one of them?
* I'd really like to see a front door to the Conductor app.
I'm
afraid to call it a "dashboard" because then it will never get
built :). I'd love suggestions for what should appear on such a
thing.
I understand the reluctance but I hate to say that this ACTUALLY sounds like it's
consumer oriented.
* Other UX work
* I think we should be able to launch single images from Conductor
without requiring a deployable XML.
Why? What if we didn't provide such a feature in the short term? What would that mean
to a potential customer?
* Status reporting
* We should reliably display the status of a running instance and
its uptime
Sounds good!
* Users should be able to view an audit trail of events for an
instance or a set of instances
Indeed, but in the short term?
* We've been saying for a very long time that we need a real API
for
managing Conductor and for doing instance stuff in Conductor. If
we admit that we have to manage instances that are not part of
deployments, then we can also just say that the Deltacloud API we
expose only works for instances. I think this is good enough for
the next release.
Who benefits from the API? What can we NOT achieve without it?
* Documentation
* I'd like to see the community get into the habit of creating or
updating wiki how-to pages as we go along. I'm not sure exactly
how to promote this (free beer once a month to the best new
page?), but I am fairly sure we do need to make the infrastructure
a little easier to deal with for it. Like it would be good if the
wiki didn't become unreachable a lot, the way the Redmine wiki
seems to do.
YES please!
OK I wil stop now. You're all going to get bored and irritated - if you aren't at
least one of those already.
My main questions around all of this are, to flog a dead horse:
What are the stated goals (ie epics)?
What is the fastest way to achieve those goals?
I see lots of cool features but very little traceability to achieving some desired,
high-level outcomes. Mostly it appears to be about achieving a vision for a fantastic
ideal.
I know many in marketing would have use believe we only have one shot at this and we
don't want to "piss off" potential customers but IMVHO, if a potential
customer won't give us a second look down the track, it's because we don't
have a compelling story not because we pissed them off earlier.
What I feel we need is real-world feedback. I would hazard a guess that if a random
developer could: $ /usr/bin/ruby -e "$(curl -fsSL
https://raw.github.com/gist/somegist)" and install everything, they would start
contributing back and adding features they NEED almost right away.
</rant>