Excerpts from Nick Coghlan's message of 2013-02-21 11:51:50 +1000: > On 02/21/2013 08:49 AM, Dan Callaghan wrote: > >> As far as providing the recipe ID goes, perhaps a BEAKER_RECIPE_ID > >> environment var would be better than a file? That should be easier to > >> make consistent cross-platform, and also matches the way we provide URL > >> details. > > > > Yes. Setting system-wide environment variables in a cross-platform way > > has its own difficulties, as I mentioned, but it makes things simpler on > > the harness side so it is probably the best choice. Although if we used > > an environment variable for this I would just pick RECIPEID which is the > > existing name that the harness exports to tasks. > > The concern I have with a relatively generic name like "RECIPEID" > (depending on how generic you consider the term "RECIPE") is that we're > going to be encouraging the installation of other harnesses, and name > conflicts becomes a potential concern. I'd really like all of our > environment based configuration settings to have the "BEAKER_" prefix.
Okay, that's fair. Actually there are two different sets of environment variables at play here, and I was conflating them. There are the environment variables exposed to "RHTS-format tasks" (which is actually *all* tasks, but we are using that term to justify keeping the old names for everything). These names are entrenched and we can basically never change them. They include things like RECIPEID, TASKID, REBOOTCOUNT, etc. I actually have a bug for 0.12 to document these [1]. *But* if Beaker is going to use environment variables to communicate to the harness, we don't necessarily have to re-use the same variable names. It will be the harness' responsibility to set the "RHTS-like" environment variables for the tasks, if the harness supports "RHTS-format tasks". So there is really no reason to stick with the (potentially colliding) "RHTS-like" environment variable names in our new API. Let's go with BEAKER_RECIPE_ID. [1] https://bugzilla.redhat.com/show_bug.cgi?id=872421 > A task library based harness migrating to the stable API can easily do > "RECIPEID = BEAKER_RECIPEID" for compatibility with existing tasks. Right, or to be more precise I would say, a harness that supports "RHTS-format tasks" can do that. There are plenty of people who are interested in running the same old tasks, just from git directly. > > Now that I think about it, it makes more sense to expose the base > > URL of > > the proxy (or of the lab controller, if you prefer to think of it that > > way) and then define the harness API in terms of paths relative to that. > > How about: > > - BEAKER_LAB_URL > - BEAKER_HARNESS_API > > I think there's an advantage to providing both: > > 1. providing BEAKER_LAB_URL means harnesses migrating from the old > XML-RPC API can work around any gaps in the stable API rather than it > being an "all-or-nothing" transition Well I don't think we should care about this. Right now anyone who is talking to the XML-RPC API has already hardcoded it as http://$LABCONTROLLER:8000/. Or I guess you are saying, at least we can encourage them to change it to $BEAKER_LAB_URL without forcing them to also switch to the completely different HTTP API? > 2. providing BEAKER_HARNESS_API preserves *our* flexibility in the > overall URL design of the lab controller Hmm maybe. I am worried we are introducing a false distinction though, between "HTTP resources exposed by the lab controller for harnesses" vs "HTTP resources exposed by the lab controller for test systems". Just because something is currently handled by the harness (as opposed to, a kickstart %post script or something) doesn't mean it always will or won't be. A truly hypertext/RESTful view would be that it's not even an API, but rather just a collection of HTTP resources exposed at well-known names. It shouldn't matter whether it's a harness or some other piece of code using them. Maybe it is a mistake to even call it a "harness API" at all? I think of it more as "lab controller HTTP resources which happen to be useful for the harness", though that makes for a more awkward document title. :-) > > Yes in theory all access to the outside world should happen through > > the > > proxy. But there is one big exception to that currently -- fetching > > tasks from the task library. > > > And I agree that in hindsight calling the variable just BEAKER was maybe > > not wise, but this particular bike shed has already sailed :-) It's not > > documented, because none of that stuff is, but that variable has been > > available since 0.9.1 so I wouldn't want to take it away in case people > > are relying on it. > > As with RECIPEID above though, so long as people are aware of the > change, aliasing it back to the old name on the client side is fairly > trivial. > > Given the rationale for providing it, I suggest BEAKER_TASK_LIBRARY_URL > as a new name. Harnesses that don't need to access the task library can > safely ignore it, those that expect it to be available under the old > name can alias it as "BEAKER = BEAKER_TASK_LIBRARY_URL" Sorry, I wasn't clear in my reply. I was answering two questions in one. Beah fetches task RPMs from the server but only indirectly -- it just does yum install, and then yum fetches it from the server repo (which is added to /etc/yum.repos.d by the kickstart). So yes, for lab segregation purposes all traffic is theoretically supposed to go through the proxy, but this one is big exception where it doesn't. That said, the harness itself *doesn't* need to know the server's URL for this, it's preconfigured in /etc/yum.repos.d. The env var BEAKER is set for tasks, but the harness doesn't use it. And since we don't want to encourage the harness to talk to the server directly, we should just drop it from the API altogether. -- Dan Callaghan <dcall...@redhat.com> Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
