Space Shuttle Discovery rolls out to the pad

Discovery on the crawlerway - 1 hour into its journey to the pad
Space Shuttle Discovery rolling out from the VAB to the launch pad
Discovery begins rollout from VAB to the launch pad (STS-120 mission)
… Discovery begins rollout at 7am EDT.

This is a major step in space shuttle processing. Discovery has been mated to the tank and external rocket boosters inside the Vehicle Assembly Building, or VAB for short. Now it is time to go the launch pad, where further work will be conducted. Most importantly, the payload will be integrated. Ffor STS-120, this is the International Space Station’s (ISS) Harmony module.

The rollout is performed by a gigantic “crawler” which moves the Space Shuttle stack (tank, boosters, orbiter) at a very slow speed to the pad. It is a 3 mile journey and takes around six hours.

The move can not be done if there is bad weather predicted. This is the reason why the rollout had been delayed for some hours. However, the rollout was move ahead of schedule, the current rollout is even a bit before the actual schedule. So far, the target launch date of October, 23rd is still very possible. There is even a day of contingency (spare time) left in the “processing flow” (aka “launch preparations” or “getting it ready” in less technical terms;)).

I will update my blog with additional pictures during the rollout. I also plan to create a short animation of the rollout once it is over (depending on my ability to capture enough images).
Picture Sources: NASA TV, NASA Webcams

Payload Canister delivered to Launch Pad…

The STS-120 payload canister is being delivered to the launch pad
Yesterday, the Payload canister has been delivered to the launch pad. What can be seen is the “protective cover” of the canister. It is now being stored at the pad. After Discovery has been moved over to the pad (starting on Saturday evening), the payload will be integrated into it (at least this is what I think will happen – remember, I am still learning…).

I’ve also heard that the weather forecast looks good for the rollout. Processing flow in the VAB still seems to be great, so the rollout as scheduled is very likely. However, this seems not to bring in extra contingency, as some work usually done in the VAB seems to have moved over to the pad. The reason was weather, where the favorable weather on Saturday shall be used. In any case, the NASA guys are doing an excellent job.

So far, everything still looks like an October, 23rd launch is still quite probable.

on ommysql packaging

I thought I share an interesting conversation that went over the rsyslog mailing list. Even though it buried in the mailing list archive, I think here is a better place to be displayed. Feedback is much appreciated.


> —–Original Message—–
> From: Michael Biebl
> Sent: Friday, September 28, 2007 10:23 AM
> To: rsyslog-users; Rainer Gerhards
> Subject: Re: [rsyslog] rsyslog 1.19.8 released
>
> 2007/9/27, Rainer Gerhards :
> > repeat message processing. The MySQL functionality is now taken out
> of
> > the core package, but its tarball is still contained in the main
> tarball
> > (so it is still a single download for everything). This is part of
> the
> > effort to fully support third-party plugins. Rsyslog 1.19.8 is a
>
>
> To be honest, I don’t particularly like this change. It increases the
> work for package maintainers (like me). You now have to maintain two
> source packages. Having a non-standard tarball inside a tarball
> doesn’t help there. It even worsens things, as stuff like “make dist”
> or “make distcheck” doesn’t work anymore for a cvs checkout.
> There’s also the problem of which version of the plugins will be
> compatible with the core version (upgrade scenarios, keeping them in
> sync, etc.)
> It also adds complexity for the developer (as he has to maintain an
> additonal set of build files).
> As you were talking about 3rd party plugins (with the emphasis on 3rd
> party) I don’t understand the benefit of splitting out the mysql
> plugin as it is you who develops the mysql plugin, not a third party.
> Do you actually intend to create a separate tarball for each plugin in
> the future?
>
> What was wrong with the –enable-mysql configure switch? I don’t see
> any benefits, only disadvantages. You know, if it ain’t broken, why
> fix it ;-)
>
> Cheers,
> Michael

Hi Michael,

as I have blogged, I am not yet sure about how to handle the situation. I am also consulting with Autotools experts, any advise is appreciated.

Two packages seem useful, especially when more plugins become available (I myself think about email and a couple of other databases). Many folks also do not like the idea of having to have libmysql present on the system just to install rsyslog – with a core package and the plugin, those can only install the core (and that will probably the majority of cases).

What I have not yet found – and I have very limited expertise in this area – is how to do that in the best possible way.

Oh, and some more background: ones the plugin interace has matured (I expect this in 3 to 6 month), I intend to actually use ommysql with its own version number. Versioning will be handled by the interface (that part is already present, but no code for it yet as there is only a release 1 of it). So, in the medium to long term, ommysql *will* be a separate project – maybe one with a different maintainer, as I am no mysql guy.

Does this make sense? As I said, comments are much appreciated…

Rainer

It was not a MLP…

Look at the red circle and you will see it can't be a MLP
In my last posting I thought I had spotted a mobile launcher platform. But I was wrong. As a friend pointed out, it can not be. Look at the red circle – this is a table. It would be a real gigantic table, if it were a MLP. So it can’t be…

changed the blog url

Yesterday, I talked with some of my friends about the blog. They said: “hey, cool, but what do you do after 2010?”. I was stunned. But, yes there are right. In 2010, the space shuttle is retired. Some years later (hopefully sooner than later), the Ares rockets will launch cargo and humans into space, to the Moon, hopefully to Mars and at some distant time even beyond that.

When I started this blog, the main intension was to provide a trip report from my launch viewing. But it is also interesting to write about all the cool things that go together with launch preparations. So I may continue to drop a post or two on future missions. And, of course, I will try to view an Ares launch when it is time to do so (though I guess tickets to the first human flight will be very hard to get hold off).

Writing about Ares under shuttlelaunch.gerhards.net? No, that sounds strange. So I have changed the blog url to spacelaunch.gerhards.net, just to be prepared for the new things to come. And, hey, you never know if some friendly folks will sponsor me a trip to see an Ariane or Russian launch… ;)

I have set up a redirector to redirect traffic with the old urls to the new ones. In the first day, that may not work very well (due to technical issues, for the geeks: DNS propagation delay). I’d also appreciate if you could update your bookmarks. Sorry for any hassle this url change causes – but I think it has a good reason…

Is this a mobile launcher platform?

Is this a mobile launcher platform (MLP)?
I found this picture on one of the NASA webcams. I wonder if it is a mobile launcher platform (MLP)? If so, is it the one to be used for Discovery? I do not know enough about VAB processing flow, but it might be that the full stack (orbiter, boosters, external tank) be assembled first. When this is done, they might be lowered to the mobile launcher platform. If that’s the case, then my speculation will probably be right. If anybody knows for sure, please drop me a comment. And, of course, I’ll also try to find out…

work log for 2007-09-26

work log for rsyslog:

2007-09-26
– applied patch provided by varmojfekoj to support building ommysql
in its own way (now also resides in a plugin subdirectory)
– fixed a bug in cvthname() that lead to message loss if part
of the source hostname would have been dropped