Thanks for writing this all out! ----- Original Message ----- > Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm > new to the project. I only mention it again because it's relevant in > that I missed any of the discussion on why proxying from tuskar API to > other APIs is looked down upon. Jiri and I had been talking yesterday > and he mentioned it to me when I started to ask these same sorts of > questions. > > On 12/11/2013 07:33 AM, Jiří Stránský wrote: > > Hi all, > > > > TL;DR: I believe that "As an infrastructure administrator, Anna wants a > > CLI for managing the deployment providing the same fundamental features > > as UI." With the planned architecture changes (making tuskar-api thinner > > and getting rid of proxying to other services), there's not an obvious > > way to achieve that. We need to figure this out. I present a few options > > and look forward for feedback. > > > > Previously, we had planned Tuskar arcitecture like this: > > > > tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc. > > My biggest concern was that having each client call out to the > individual APIs directly put a lot of knowledge into the clients that > had to be replicated across clients. At the best case, that's simply > knowing where to look for data. But I suspect it's bigger than that and > there are workflows that will be implemented for tuskar needs. If the > tuskar API can't call out to other APIs, that workflow implementation > needs to be done at a higher layer, which means in each client. > > Something I'm going to talk about later in this e-mail but I'll mention > here so that the diagrams sit side-by-side is the potential for a facade > layer that hides away the multiple APIs. Lemme see if I can do this in > ASCII: > > tuskar-ui -+ +-tuskar-api > | | > +-client-facade-+-nova-api > | | > tuskar-cli-+ +-heat-api > > The facade layer runs client-side and contains the business logic that > calls across APIs and adds in the tuskar magic. That keeps the tuskar > API from calling into other APIs* but keeps all of the API call logic > abstracted away from the UX pieces. > > * Again, I'm not 100% up to speed with the API discussion, so I'm going > off the assumption that we want to avoid API to API calls. If that isn't > as strict of a design principle as I'm understanding it to be, then the > above picture probably looks kinda silly, so keep in mind the context > I'm going from. > > For completeness, my gut reaction was expecting to see something like: > > tuskar-ui -+ > | > +-tuskar-api-+-nova-api > | | > tuskar-cli-+ +-heat-api > > Where a tuskar client talked to the tuskar API to do tuskar things. > Whatever was needed to do anything tuskar-y was hidden away behind the > tuskar API. > > > This meant that the "integration logic" of how to use heat, ironic and > > other services to manage an OpenStack deployment lied within > > *tuskar-api*. This gave us an easy way towards having a CLI - just build > > tuskarclient to wrap abilities of tuskar-api. > > > > Nowadays we talk about using heat and ironic (and neutron? nova? > > ceilometer?) apis directly from the UI, similarly as Dashboard does. > > But our approach cannot be exactly the same as in Dashboard's case. > > Dashboard is quite a thin wrapper on top of python-...clients, which > > means there's a natural parity between what the Dashboard and the CLIs > > can do. > > When you say python- clients, is there a distinction between the CLI and > a bindings library that invokes the server-side APIs? In other words, > the CLI is packaged as CLI+bindings and the UI as GUI+bindings? > > > We're not wrapping the APIs directly (if wrapping them directly would be > > sufficient, we could just use Dashboard and not build Tuskar API at > > all). We're building a separate UI because we need *additional logic* on > > top of the APIs. E.g. instead of directly working with Heat templates > > and Heat stacks to deploy overcloud, user will get to pick how many > > control/compute/etc. nodes he wants to have, and we'll take care of Heat > > things behind the scenes. This makes Tuskar UI significantly thicker > > than Dashboard is, and the natural parity between CLI and UI vanishes. > > By having this logic in UI, we're effectively preventing its use from > > CLI. (If i were bold i'd also think about integrating Tuskar with other > > software which would be prevented too if we keep the business logic in > > UI, but i'm not absolutely positive about use cases here). > > I see your point about preventing its use from the CLI, but more > disconcerting IMO is that it just doesn't belong in the UI. That sort of > logic, the "Heat things behind the scenes", sounds like the jurisdiction > of the API (if I'm reading into what that entails correctly). > > > Now this raises a question - how do we get CLI reasonably on par with > > abilities of the UI? (Or am i wrong that Anna the infrastructure > > administrator would want that?) > > To reiterate my point above, I see the idea of getting the CLI on par, > but I also see it as striving for a cleaner design as well. > > > Here are some options i see: > > > > 1) Make a thicker python-tuskarclient and put the business logic there. > > Make it consume other python-*clients. (This is an unusual approach > > though, i'm not aware of any python-*client that would consume and > > integrate other python-*clients.) > > -1 in favor of #3 below (spoiler: I'm -1 to that too, I suppose this is > a -2) > > > 2) Make a thicker tuskar-api and put the business logic there. (This is > > the original approach with consuming other services from tuskar-api. The > > feedback on this approach was mostly negative though.) > > A tentative +1. Tentative until I dig up the feedback on intra-API calls > and see why it was negative, in which case I may buy into those > arguments too.
I'd be +1 for this; I don't fully understand why intra-API calls are negative either, was there a previous thread that outlined the deficiencies? In fact, I'd advocate going a little bit farther than what we did in the demo iteration. Here's a specific case: For the demo, it was decided that the UI would call the Baremetal API directly for things like registering nodes and retrieving a node list. That seemed to make sense at the time. Later, we realized that Tuskar had its own concept of a node (used for node/rack associations). So we had to make two separate queries and outer join the two, which led to some convoluted logic in the UI, and left me wondering - wouldn't a CLI need to use exactly the same logic? It would make more sense to me to push that sort of thing into the API. > > 3) Keep tuskar-api and python-tuskarclient thin, make another library > > sitting between Tuskar UI and all python-***clients. This new project > > would contain the logic of using undercloud services to provide the > > "tuskar experience" it would expose python bindings for Tuskar UI and > > contain a CLI. (Think of it like traditional python-*client but instead > > of consuming a REST API, it would consume other python-*clients. I > > wonder if this is overengineering. We might end up with too many > > projects doing too few things? :) ) > > This is the sort of thing I was describing with the facade image above. > Rather than beefing up python-tuskarclient, I'd rather we have a > specific logic layer that isn't the CLI nor is it the bindings, but is > specifically for the purposes of coordination across multiple APIs. > > That said, I'm -1 to my own facade diagram. I think that should live > service-side in the API. > > > 4) Keep python-tuskarclient thin, but build a separate CLI app that > > would provide same integration features as Tuskar UI does. (This would > > lead to code duplication. Depends on the actual amount of logic to > > duplicate if this is bearable or not.) > > I don't know the level of logic duplication that would happen, but the > design feels wrong from the start. > > > Which of the options you see as best? Did i miss some better option? Am > > i just being crazy and trying to solve a non-issue? Please tell me :) > > I'm not saying you're not crazy. I'm saying you're not alone in being > crazy if you are :) > > > Please don't consider the time aspect of this, focus rather on what's > > the right approach, where we want to get eventually. (We might want to > > keep a thick Tuskar UI for Icehouse not to set the hell loose, there > > will be enough refactoring already.) > > Thanks > > > > Jirka > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
