On 07/25/11 - 09:51:45AM, Matt Wagner wrote:
On Mon, Jul 25, 2011 at 09:17:27PM +1000, Simon Harris wrote:
> Some ranting and raving as a VERY newbie guy on the project:
I think a fresh perspective here is really enlightening. Thanks!
> 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...
I'm not sure if this is exactly what you meant, but I'd love to see the
project made usable out of the box -- someone could sit down, install it
on a box, and actually manage things in the cloud with it. About a month
ago I walked some people through how to use our software as it existed
then, and they were really not impressed with its usefulness at the
time. I think we've come a long way since, but to your point, I'd really
love to sit someone down and see them try to use this to see just how
far we've come.
Yes, this is what the packaging effort is all about. But what this has
highlighted is that in spite of our efforts to simplify things (and we've done
a lot of that), our dependency list is still massive. I think we need to take
another look at some of this stuff and see where we can further simplify,
because it is still impossible to get the right list of dependencies without
us having done it for you.
> > * 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
We know we're going to need authentication and authorization to work if
any sort of large organization is going to use this, and talking to some
potential users, they were somewhat put off by the lack of integration
with, well, anything they might already be using.
However, I do see your point in wondering if this is the most pressing
need of our project right now.
> > * 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?
As someone that was briefly responsible for managing a small company's
LDAP setup, I have to say, "Dear God, yes" here. I'm also not sure that
this needs to be a complicated UI to put together.
As a tangential note, "Fall back to a local user data store" strikes me
as backwards. I'd think that locally-configured permissions should take
precedence over whatever external authentication we use. It just feels
right -- it's more local and thus feels like it should be an override,
and it also means that you won't get potentially-bizarre results if the
external LDAP server goes down. But I'll happily defer to others who
have more experience here if appropriate.
> > * 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)
There's no reason to assume that these processes are running on the same
box. So without authentication, the worst-case scenario is that you're
able to eavesdrop on network traffic between Conductor and Deltacloud
(for example) and obtain the credentials that are passed around in
cleartext. (Another bad case is that people realize it's passing this
information in cleartext and don't use it in the first place.)
Encryption is absolutely essential between the components, because lack of
authorization/encryption at certain points means that rogue users can inject
arbitrary data into running instances. That is, um, less than ideal :).
> > * 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 hope I'm seconding what you say and not hijacking your point, but here
goes -- I think a really slick and polished UI is very important, but I
also think that having ugly features is better than not having the
features because we haven't decided how it should look yet.
The way I've typically seen this done on other projects is that we'd
develop "ugly" pages that implement the functionality, and then, when
the UI was ready, we'd apply the new styling or change the layout to
match. Here, we're doing it the other way -- not implementing features
until the UI is ready.
> > * 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.
I think the main page when you log in -- the pools#index page, is
already meant to be a 'dashboard' of sorts, showing you an overview of
your utilization, etc.
If we do decide that a "dashboard" is needed, could I humbly propose
that we determine exactly what customers would expect to see there?
> > * 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?
Creating XML files and using command-line tools is really off-putting to
potential users, at least the ones I spoke with.
I think we want to make it easier for potential customers / users to get
started. It's already fairly complicated to set up and use; telling potential
customers to craft XML files to feed to our web interface feels almost
> > * 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?
I still don't understand why this isn't a 20-minute task -- when you "do
something", log the action, user, and time to the Events table in an
after_save hook. We've been talking about wanting this sort of trail for
months, so I suspect it's more complicated, but I don't understand why.
The problem is collecting the information. Sure, it would be a 20 minute task
to get everything from the rails app, put it in a table, and then wrap UI
around it. But it wouldn't be very interesting.
What's actually interesting is what is happening in the outside world. Things
like when your instances started in the backend clouds, when they stopped or
crashed due to outside influence, etc. This requires integration with the
scheduler to get that stuff, and then put it in the database. It's
still not a huge task, but it needs a bit more munging to make it work.
> > * 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?
I think most everyone agrees that we're going to want an API. But to
your point, I'd really like to see use cases here, because I have a hard
time visualizing exactly how it will be used, and I'd rather not go
through the effort of implementing an API just for the sake of saying we