Hello. So let's give people a minute to join here or so due to the issues to meet in password. And I also put it into the documentation. There it is now. The image is put in there. All right, as always, I'd ask you to add yourself to the meeting notes. Seems to be. Let's give people maybe couple more minutes to join before we jump into the topics right now. Hello. Okay, then let's get started. Let's see how people are showing up. So for today, couple of updates. The first one is on the operator working group. When I joined the last couple of meetings. We decided to merge the working groups back into the main meeting here from the presentation working perspective also because they are at least some of those meetings that did not really have didn't have a lot of attendance we also had hand and all together so we thought let's move it into the main meeting. Also some of those meetings, I tried to join them nobody really showed up to those meetings will be tried to put the work back into one meeting. And we can split things further out as we know, but obviously people can focus on what they interested in and this is true for both the air gap work, as well as the work on the the operator definition. The first topic. I want to work on. I look into is that that working document we had on the the operator definition. So this document has been around for for quite a while now with. I'd say limited progress on the document per se. I last meeting I took the action item to comment pretty much on all the action items that were in there in this document. And to really move this forward so this was also requested by that you see that we come up with a better documentation for a better definition of what an operator is. And I just briefly take the time to go over a couple of items here. So the first discussion item was that this related to technology section in here. It created some kind of confusion that people said well this is not necessarily presented right not all technologies are in there. And the last time you already discussed that for the related technology part it's not even really necessary for this document so the goal of the document to describe what an operator is, but not necessarily to define what other possibilities are out there to run different technologies and what could be used as an alternative to some of the capabilities of an operator. So the proposal was to remove the section this has been now around for almost a month to remove the related to our technology approach session. So the question is that anybody object which has removed the section really focus on the core definition of the operator. I think it would make sense to describe some other technologies in short sentences but only to distinct between the operator and other technologies. So I think we should we should define when when an operator totally makes sense and when does it make no sense when it's when it's better to use charts or other things. But is it really our job to tell people when they should be using which technologies when that main goal was just to describe what an operator is. No I don't think so. And that was the driver because I'm that this was like Matt's comment here. On the help side this is not an accurate description of what help is doing which I might agree with to some point, but nobody. So people were complaining okay this is not accurate enough that we will put it in there. At the same time there was no update so my point was let's focus on describing what the operator is how it works or how it's supposed to work. And leave the section out because it created a lot of confusion in the past. This would make total sense. And we have some others in there and if somebody wants to take the section to a level where it's fine we can leave it in there so Thomas if you want to take it. I could try it until the next meeting. Yeah so please get in touch with Matt whether he's fine and maybe some of the other project I think we don't necessarily need it honestly. I think it doesn't really help us. Just taking it out here. So I'm not sure if someone read it. I've posted something on the mailing list to give to document a bit of another structure, but didn't get any response until now. So, yes, I think I'll also discuss this with Matt. Okay, so you get the action to remove it or not. Is there what do the other people think should we have it in there should we remove it. Maybe we can also discuss your offer later on in here to provide a link to your document in here as well. Okay, so let's look at some of the comments in here. This I want to later on discuss a bit. I was struggling with this. So this was like a feature creep. Most of this document. If you want to put it that way that say who's the audience of this document and we started while the TUC requested it which would mean it's a very technical audience obviously we extended it to to technically kubernetes app developers and cluster operators. Which I think also makes sense if you're building an app, or if you're operating an app on a committee discuss the you should understand what an operator is that they totally make sense. What I kind of is totally out of scope for me a director of a non kubernetes company to understand what an operator is. I was back then part of this meeting but I think we're still struggling with the technical definition of what the operator is. So I remember the back to the day when we had this discussion was yes my boss he's not like super technical I want to implement an operator and I want to give him a document that he understands why I want to do this. My proposal is to remove non kubernetes users from that operator definition, especially if you don't understand how kubernetes works it's like very hard to understand what an operator is. And that I agree with that that that is very weak because director in a company could mean different things depending on the company. It is to remove this as a target audience, I mean if we could if we want to have an operability guide later on. I'm fine doing this but it just makes like super super wide. So anybody okay so then is there any reason why we are explicitly calling out at developers only in the line number two. Why not, you know, DevOps sari kind of a person us. And as the users to target audience. Yep. I mean I was at the CNC FTC is is a target audience but they may we're writing it because we're building it for that you see request. I think that makes. And so, and I removed the technical here I think it's kind of like repeating itself. I have for, I have luckily really seen on very few untechnical app developers cluster operators and you said SREs. Yes. I'm also if you're fine I'm moving this into FTC to explicitly mention it. I think it's not adding any massive value here. I mean obviously it is for the TSE but yeah so just that that I ask for your permission all the time if you do not agree simply speak up or agree if you have an opinion, then I think that that would be good so this is you so you're either developing an application you're running a Kubernetes cluster or you're an SRE that is obviously responsible for an application that is running in Kubernetes. Good. I know this sounds like baby steps but it is some progress here so and then note in here. So, so an operators in the in cluster application which uses declarative paradigm for the installation configuration and operation of an application that was a comment that that Tom put in there and the working group so I think the only discussion in here is what about operators that are built for non Kubernetes cluster resources, something like a CK. I don't know if you're familiar with a CK but a CK is the operator that allows you to manage Amazon easy to or AWS resources. I think this is okay. Well technically they're not calling it an operator they're calling it a controller for Kubernetes. And I think that the bigger question here is, I think how you look at this conversation with Cornelia last week in the operator meeting because I think that both of us showed up in that meeting and had some discussion. I think it's how you see Kubernetes do you see Kubernetes as more or less as a platform to build platforms and operators as a core concept in there. Or do you see it really as a means to run container type workloads. Okay is an example here is maybe this is something we could put Thomas in the related technologies. They even say that it's just a control they don't name it to call it out as an operator because it's not managing anything inside. I think this is similar to cross-plane isn't it. So also just a set of controllers and control plans to build other other platforms or to control other other things. I think it's, but what I still like to do in here that sentence per se is not wrong. Just want to operate this help its consumer to manage the life cycle of the resource without the need to run any code. And we can. So, because none of these comments had like a lot. I would really move the out of cluster discussion to I would rather make a separate comment for this one. Then I was it goes deeper into this. Yeah. Can an operator be used to update in another operator. Theoretically as I think so. Should we include that then because it's only talking about applications. Unless we start call operators another application. And if you're. I think if we could be more precise what we mean by by an application for instead of kubernetes because in kubernetes there is nothing that's an application. You have a number of resources that you can update in kubernetes and the application is none of those resources so technically you would define an application. You would need to have a custom CD. Yeah, I think that that's actually a good point should be named what what you can actually control what you should be controlling with it. I'm just adding this here as a. Sorry. As a comment. I think you cannot double comment. I think another application could be replaced against a set of objects or objects or however you want to, you want to name it. I think we should name the objects that you usually control by like. But that's a good point. We should really call it out because an application per se does not exist. So, and I think then it goes into okay what an operator is not meant to do monitor an application they can observe and utilize metrics lots of events to support the proper function. But they're not used to do that in a deeper sense. So yeah, I already commented on this one I'm not really understanding what we mean obviously there is a reconciled loop, but it's not a log shape or a log agent per se. I think this relates to the. But technically I could explore. I could also write a CD based on the resource. Yeah, it's not replacing a monitoring system. What is this coming from is this operator capability model that was initially core as than redhead resistors like phase one, which is basic installed and there are seamless upgrades for life cycle deep insights and and auto pilot for for an operator. Now, now that I read this document a bit. With some distance, I feel at that point in time I still have no idea how to what to do how to build an operator in kubernetes. I think it's very abstract but I don't know what it is how to build it like for my if I'm the developer. I still don't know what I should be building right now. I mean we know you want to have a custom controller that is implemented. You should have a CRD for this customer for the custom controller. There's a recon sound loop in which you should react to what you're doing, but none of this is anywhere here. So I don't know how you feel about this but this is, I think we might want to go like one level deeper like this is if we talk about kubernetes operators context of kubernetes. This is the core part of the kubernetes architecture that's relevant to operators and this is how you extend kubernetes with like an operator or how you add additional functionality in there.  But if you look at the initial definition in there is because there is one in the kubernetes documentation, operate the pattern here it is. There's the aims to capture the aim of a human operator who is managing a service a set of services. Human operators look after specific applications and services have deep knowledge of how the system ought to behave how to deploy it and how to react. If there are problems people who run workflows on kubernetes often like to use automation. Okay, that's fine. Operators in kubernetes kubernetes is designed for automation out of the box you get lots of building automation. You can use kubernetes to automate deploying and running workloads and you can automate how kubernetes does that kubernetes controller concept. Let's you extend the cluster behavior I think this is something we should put in there you extending what the cluster can do. So this is I think number one that's not in there it wouldn't be there. The operator that doesn't manage this is a way how you can extend a kubernetes cluster with additional capabilities. You can use that's the extended cluster modify the code of kubernetes it's without modifying the code of kubernetes itself. Operators are clients of the kubernetes API's that act as a controller for a custom resource. So okay I think that's I think that is a bit more specific but what I think might be helpful is like having a picture like usually when you have an operator like these are your major building blocks that that you have. Like your custom resource your controller component these are like this is your reconciliation loop or this is your interaction with the kubernetes API. This is where you basically build almost like that there might still be like a 10,000 feet view of this but a bit more focused on the developer here. There's a couple of more examples down here like deploying an application on demand taking a restoring a backup. Handling upgrades of the application code along several changes without publishing a service with patients. Simulating failure a custom resource that's another example is a custom resource and sample to be that you can configure into the cluster. A deployment that makes sure a part is running that contains the controller part of the operator. A container image of the control code that queries the control plane to find out what the sample to be. Actually this putting this maybe in a graphics might be in a graphic might be a nice way of actually describing it. So first you have your custom resource. Then you have a deployment for a part and a container that actually contains Europe. That contains your controller. Here we have the container image. Controller code that queries the control plane to find out what sample to be resources are configured with consideration loop. The core of the operator code is to tell the API server how to make reality match the configured resources. If you add a new sample to be the operator sets up a persistent volume claims to provide durable data storage a stateful set to run sample to be and a job to handle the initial configuration. If you delete it. The operator takes a snapshot then make sure that the stateful set and volumes are removed. The operator also manages regular database updates for each sample to be resourced the operator determines where to create the parts that can connect to the database and take back up these parts would rely on a config map. If the most common operator is to add the custom resource definition it's a little bit controller to the cluster. The controller will normally run outside of the control plane. If you would run any containerized application for example you can run the controller in the cluster as a deployment. So I think that sample to be this list by the way they also extended to think that older documentation didn't have all of them in there. This cooler cube with the controller. And the operator framework in there. But I think putting something like this in moving something like this over into the dock. That would actually be helpful. I think now I understand by like even having a picture that okay this are the components that you have this is what it's doing. So, if you do not disagree I would move this part over. I think we need to then see how it better fits fits in there. So this is the whole discussion of people don't like phases, but again there was. For example last year, no more comments. So I'm just closing this one. So what I, what I think would be a good idea is we have like this high level description if you could have if you want to use the phases. We have a description how what an operator usually always does in the individual phases would like as per our sample to be example do certain things. Like how would it handle an upgrade. That's the only way to do it. But it gets more interesting when we talk about for life cycle, especially also the deep insights bits and pieces how it would do that. And also like the autopilot type of a project, having one example what it, what it could be doing. Does this make sense. So, would it make sense to define a sample use case at the beginning such as the sample to be. And then, and then describe the describe the whole operator thing based on that. Yeah. That's why I hope it over the sample to be the question is do we just take sample to be or do we need a better use case. So starting with sample to be is not the worst of ideas as we're going to need to start it with sample to be as well. I'm putting it in the notes. This could be an example application so we just need to this have one in there we could also have an application that's more complex. Maybe one that has a state folks that has some additional resources it's managing. Yes. Okay. Do you want to write it Thomas. This is also almost a year old and April. So the main takeaway was the way it, the only way an operator right now can, what is monitoring application is why are that the Kubernetes API. So everything you can query via the API it would know about that if a pod died or if something happens. But I think an operator can monitor a bit more because you also can talk to the application itself. So you could monitor have that points. Yeah. Okay, good morning. Should we have a separate point maybe on the monitoring piece how and that an operator could monitor it yet. Some kind of absurdly the features are into the operators the case far as I know, I think it would make sense. It's greatly confusing for us to say that operators are not meant to then monitor an application then talking about few things to monitor. I mean I feel like it's, it's confusing saying that it's, we're kind of conflicting ourselves in that statement. Yes. Yeah. You mean because further down here we talked about that we have posted on monitoring the application. Yeah, especially if it is one of the key faces. Yeah, I think the idea was that they are not replacing a monitoring system or like an observability system that you're running. And they only monitor the application to the extent that they need to do their job that they are designed to, which technically doesn't them limit them doing anything really. I'll put this in here. It's confusing given. Yeah, maybe we'll remove it. Potentially we can add a, I don't know, something like the sample operator that we have we could add a use cases, and in that use case section we can see that not meant to use in this like prolonged monitoring of an application in communities. But aren't the use cases the faces, more or less like how do I do, say like full life cycle management and if you zoom in a little bit, you would have like backup failure recovery. What do you think of the other. Yeah. Yeah, but it's a good point to describe that for this use case how you would actually address it. So I like the idea what they took, the way they took it in the company to stop examples on making examples just capital case that this is not the only way it can be done. It's just like really one example on how things could be. Yeah, this is just the same model in a different way. There's just two ways on how to present that model. Okay, here we have the implementation that we discussed before like the technical implementation. Just a quick question on the two diagrams should be include both the diagrams because the second one to me looks like sort of representation of the current population, like basic install is high and usually we use we use diagram like that to show the population. Not the life cycle or faces. I personally don't think that we need both and get just repeating themselves as well so to me we're removing this one. Yeah. So I'm just leaving it in there in case anybody wants to have it in there and I'm not expecting it but just let people comment on it. So what do you think about this one so I know we had this discussion a long time back we said what we have to distinguish operators from controllers. What do you think about it if you really go after use cases this is what you can use an operator for this is like an example of able to use it to do different things. I don't really understand why, why we should differentiate between operators and controllers, because technically an operator uses a controller and it's not another is not competing with a controller. Here's a question then, why do we even have the term operators, if they're going to be synonymous with controllers. What's the point. There has to be a differentiating factor for it to be a useful meaningful term. What it loses its original chorus purpose. If we don't distinguish it from a controller where we're, we're making it so different from the original purpose that it'll probably end up confusing a lot of people as well, because it's gone so far away. There's a controller that uses a shared informer against the core object. And could you argue that that is an operator. Just a, or, you know, just a built an object. Is that an operator then. There's a difference and I think it needs to be outlined. So basically an operator is not the controller that's true, but it's, I think an operator is just an enhancement of a controller, because it has additional features. So, so what is the difference and why I mean people need to know that. Right we're trying to explain it to people in plain English and they're going to see controller stuff all over the place. You know, distinguish between the two they're going to go what's the difference. It's why this question even came up, and we say well there really isn't any difference they're going to say, Why do we have the term operate and then other people are going to say, but chorus define this in a way that's very different than just a controller. Why are you redefining it to something that's just so general that it can be a controller. It's going to raise a lot of questions if we don't answer this. I get your point so I think we should describe a bit about this. But the question was what's the purpose I mean the way if you again look interestingly at the Kubernetes documentation. They talk about the operator pattern. So it's as small as a pattern how you can manage workloads they don't. They provide insights and how you can implement it with Kubernetes. Platform mechanisms but it is a pattern on how to do things rather than it is like an actual like core artifact of what what what we're doing and eventually people are releasing operators. So if we look at here like where the original documentation comes from it just specifies the operator back pattern. So, so Matt do you have a proposal on how to phrase this so that it helps people to say I mean, operators are a subset of controllers that do a specific pattern. And that pattern is outlined in the definition of what an operator is. Yeah. There are some controllers that implement that pattern, and there are other controllers that don't implement that pattern. And I would probably give some examples of controllers that don't implement the operator pattern to distinguish them. And an operator pattern by the way isn't just controllers right, because an operator has to extend the API and a controller doesn't extend the API. So operators a pattern also needs you to extend the API right. Yeah, whoever has good ones obviously comment on like good examples but I'm putting this in here. Yeah, then we are again at the related technologies and approaches section which Thomas has taken the action item to talk with the individuals whatever we want to keep it I think we don't necessarily need it this is not the competition here. Just help us to understand and describe the concept and help people to use that concept. And not say this concept is better than other concepts that are out there. Good. I think there's some action items in this one for the next meeting to get to give it some updates on some overhaul. I know this is kind of like a bit painful to get started with think that this will then get be more say rewarding once people who were looking at learn more about it will reference this document and say thank you to us for eventually having it put together. But I know it's. It's a bit of a, like say the challenging has to get it done in the beginning. Okay, we are almost out of time especially since we had to be able to come here a bit later. Just a quick update the app delivery landscape that Harry was kind of initiating as like not long and other will update as to I would move this to to the next meeting to talk about this also on the air gap and the air gap working group that Calculus on I reached out to them once I'll do it again for examples on the air gap environments and the work that they'd like to see. The last one to take four minutes to talk about this one so Harry and I for this also came out of the last meeting where we discussed well okay having a landscape is one thing but you know many people today are explaining about since they have landscape and it's and you know there's even parcels of the CNC and landscape that you can buy because there's so many things in there. Okay, let's build like a simple sample application that people can get started with somewhere they can use different technologies to try out okay how like a delivery use cases with it and so Harry and I decided okay let's also submit this to KubeCon and like show common examples and show it was a demo application. And last time I took the task to look into the demo application the obvious one would be hipster shop because that's the most widely used my takeaway so far however was that a hipster shop is nice to show a microservice application it means it misses a lot of things that are kind of crucial to to more real world type of application like there's no stateful workloads in there there's an issue for this. There's not really a database in there that needs to be upgraded and managed maybe even a database that itself is managed by an operator like I don't know like every test or something. Obviously it's all like one version in one here so there is no blue green type of deployment there's no cannery releasing capabilities in there by default. There's also no third party dependencies that might be requiring any secret management. And there's also not multiple stages with multiple configurations so it's kind of unsure how you would handle like this application running let's say in a pre production and the production scenario with different secrets. I would define it there. Okay, can I just also to throw another layer they've been the end users have been putting out their radars lately. And there are certain things that they've put into certain categories within those radars or whether you know use it trial those kinds of things that have been typical to radars. I haven't looked but does the hipster shop example actually follow the same patterns that they've talked about over in the radars, or is there a mismatch there. You mean on the technologies that they're using in hipster shop. Yeah, and in the way they deploy it and what they use. Does it actually follow what the end users have said, these are the things that are in the, why the adopt phase. Does it actually follow that, or did just doesn't use things that are maybe more niches that the developers of hipster shop wanted to show off. Don't think that they want I haven't looked at it but it just occurred to me. Yeah. So, interestingly, this is just the continuous delivery landscape data one would be the. So what you have in here in the adopt phase, you have flux and help in there. I'm not sure what it uses held by default or reduces just manifests think it uses both. And interestingly, if you look at the rest in there I mean there's Argo in there in the SS phase obviously it's not using anything Argo related. Jenkins X and spinner person not in there as far as I know you could probably use it. You know it's tecton. Don't think so. Well Travis you could use traffic with it. And flex in general also points out get ups is the deployment model that they talk about a get ups deployment model in hipster shop. I check it out. I think I will have to check whether you can deploy in the get up a bit of session, because you know, if this is just one of those things I mean if the end users have said this. Then maybe it's worth looking into what kind of example shows off the patterns the end users already have. So we look like we're on the same page and we're actually not just showing off cool technologies in the sense that we're actually showing off that the end users are saying are good ways to do things. And so I think it's a nice way to have synergy because then you we can actually say in the thing and the end users were talking about this and you'll see the same technologies, you can reference other things happening in the CNC often show how they jive with each other. And so it's an opportunity to reference. Yeah, I think that's also what we eventually want to do so I think we could also file request tickets or something if there's a better application out there. I'm more than happy to honestly look into it but I think putting something together for a presentation I would do two example apps. I would do one that is a microservice app, and then I would do one that's a lift and shift where you're taking a legacy app and running it inside of Kubernetes, because you end up with both situations a lot in what people want to do and how they've got to deal with, because a lot of times there's a lot of people just bring over their big thing, run it in Kubernetes and then break parts off of it or just keep running the monolith there. So sometimes having two things that show you here's how these technologies and ideas can be applied to two separate things. You don't have to break it apart in the microservices right away gives people real world path forwards that they're trying to work with. I don't have an example to tell you to use right now. I'm just taking them. I just think that we should start maybe with the cloud native one first to live my life. But as we as we have more, more more end users that also will require is okay how can I move something, but we just gets a bit more complicated because then we also this 12 factor at discussion maybe was a feed around that certain things don't work. Worked that well. I think the way it helps approach is interesting. Also the state for workloads. I think we have to have to mean that is if it's totally unrealistic to run an application that's not running a database. Well, sure, I mean, you can always take something like the Reddit approach, which is where they ran their databases and VMs and they ran them separately and then they ran all their stateless services and Kubernetes, because they weren't ready to do that migration so they did a partial I don't know where it is today if they've migrated their their stateful workloads but that was one way, and it helped offset folks as they went through this with their different trust. They were very happy to do their state for their stateless stuff in Kubernetes and then as they built up trust that you know you can move over your stateful stuff. And I've seen a lot of people have those trust factors and so I think it's good to have stateful stuff, but also think it's good to talk about people as they build trust in these kinds of shifts to be know that there are options for them in the world of shifting. I'm putting it in here and interestingly for stateful workloads there is there is an open issue in in hipster shop. I think I found taking it as that reference application and we also use it internally for some demos if you really run it in multi-stage environment is actually consuming quite a lot of resources. Like running it in a three stage environment requires quite some cluster resources obviously. So maybe something a bit smaller might be easier for people to to experiment and use CNCF technologies. But I totally like the GitOps approach actually would be nice one to see what it can actually be deployed with flux. Or how far it is a way to be able to be deployed in the GitOps mode. It should be easy. Okay, I think we are already beyond on top of the hour for this one. So yeah for the next one there is obviously some work on the operator working document. Some of that the landscape work and on the other landscape. I'll work with our team over here to see whether we can actually use it like in a flux type of deployments and use other tools in there. I mean Helen should be an obvious one. You should be able to deploy with Helm if you can deploy with manifests. But also what else they have in there from from CNCF technologies. Alright, then thanks everyone for this meeting and see you again in two weeks or in the chat and on the mailing list. Bye everyone.


For a moment, let us think back to a point in time to October the 24th, 1957, to be precise. On that date, the President's Board of Consultant and Intelligence Activities submitted its report to President Eisenhower on the status of the intelligence community's collection capabilities. With strong urging from Dr. Edwin Land, the Board called for a reassessment of the Air Force's Samos satellite reconnaissance system, then under development by the Air Force. This was a complicated system based on electrical transmissions of images from space. At the same time, the A-12 Oxcart reconnaissance aircraft proposed by CIA was given a careful evaluation. The Board held that while both were promising programs, the critical need for intelligence at that point in time warranted an interim photo reconnaissance system that could get into operation earlier than the Samos could be ready. This was a significant decision, particularly for that era. Just 20 days before, the Soviet Union had orbited the world's first satellite, Sputnik 1, from the Churitam range. The United States was still over three months away from launching its first small satellite. But the need for reliable intelligence on Soviet missile deployment was becoming more and more urgent. The so-called missile lag debate was already underway with the Senate prepared the subcommittee holding hearings on this issue. The White House responded rapidly to the Board's recommendation. Dr. James Killian, who had just assumed his new position as Special Assistant to the President for Science and Technology, arranged a meeting for the first week of December among the President, the Director of Central Intelligence, Mr. Alan Dulles, and the Deputy Secretary of Defense, Mr. Donald Quarles. At this meeting, only eight weeks after Sputnik 1, the President decided to proceed with a joint CIA Air Force interim photo reconnaissance satellite program to answer the critical intelligence questions about Soviet missiles. The system was to be based on physical recovery of film from the space vehicle. This decision marked the birth of the remarkable Corona Project. The full import of the decision, however, can be comprehended only if we recall the primitive nature of our understanding of space technology and the critical need for hard intelligence information which existed at that point in time. 57. The U-2 had already spent a year in service. It had never been intended as operational for more than a year or two. The operational life expectancy was based on the likelihood that the Soviets would in some months track it successfully and with accurate tracking data in hand, bring pressures to discontinue the flights. As it turned out, we had misjudged the Soviet air surveillance capability at the time and their radars had tracked every flight from the first. The Soviets filed a protest and a standout. After that, overflights were made only sporadically, although for three more years, the U-2 ranged over much of the rest of the world. And so we set out on December 8, 1957 to build and develop what has become known as Corona, the world's first photographic reconnaissance satellite. Its importance from today's perspective is momentous. In the weeks after Sputnik 1, there was pressure from all quarters to accelerate the U.S. missile and space program. And there was much public debate about military versus civilian control of the space program. In the perspective of that time, President Eisenhower addressed the nation. There are long-range ballistic missiles. As they exist today, do not cancel the destructive and deterrent power of our strategic air force. The Soviet launching of Earth's satellite is an achievement of the first importance. And the scientists who brought it about deserve full credit and recognition. Already, useful new facts on outer space have been produced. And more are on the way as new satellites with added instruments are launched. First satellites in themselves have no direct present effects upon the nation's security. However, there is real military significance to these launches, as I have previously mentioned publicly. Their current military significance lies in the advanced techniques and the competence in military technology they imply. For example, the powerful propulsion equipment necessarily used. On 8th February 1958, the President placed authority for all military space projects under the newly formed Advanced Research Project Agency, ARPA. The splitting off of Corona from Weapon System 117L, the Air Force Satellite Program, was accomplished by ARPA just 20 days later. At about the time CIA's headquarters was being built, project Corona was begun. It was decided at the beginning that the photographic subsystem of the Air Force's WS 117L, offering the best prospect for early success, be placed under Joint CIA Air Force Management, an approach which had been highly successful in covertly developing and operating the U-2s. The Corona Development Project staff was formed under the direction of Richard Bissell, then Special Assistant to the Director of Central Intelligence for Plans and Development. His Air Force counterpart was Brigadier General Osmond Ripland, who had served on the U-2 Development Program under Bissell. I called Manny's office and gave me pretty clear instructions of what the situation was all about because you'd done considerable homework in Washington and from then on maybe you better take it. Well, I came aboard what came to be called Corona and the manner in which I was told about it was even more informal and disorganized than that in which I'd learned about the U-2 from four years before. This time it was Bin Land and said that I had been decided at the highest level that a program would be transferred to be managed like the U-2. And he appeared in my office and said that he thought I knew a decision had been taken to shift that program over to me and I didn't know what program and I didn't know what shifting it meant and he told me it was a part of the 117-hour program of the Air Force and that it was to be managed in the same way that the U-2 had been managed. But of course he couldn't answer any of my questions about who was going to pay for it and who was doing it on the Air Force side or what the duties of the two organizations were to be. The initial problem in this program, the cover problem and security problem was very different from that of the U-2 because there was already quite widely known and defined from studies in your command of the Air Force an interim and preliminary satellite reconnaissance program that would not involve readout but the emphasis would be on fairly readily available hardware and on speed and which would run people thought for perhaps a year and a half and would as Corona eventually did produce film in a capsule which would somehow be recovered. That was a subject to which you and I addressed ourselves on our first meeting and as you have said about this time ARPA had come into existence and it seems to me a decision had been made again at the White House level that the funding would not be Air Force within the Pentagon but it would be primarily ARPA funding with the CIA funding the payload and that many of them is the way it turned out for at least the first year of the program. As I look back on it ours we do have one great advantage. Corona got underway in March 1958 at a three-day conference in San Mateo, California among CIA, Air Force Ballistic Missile Division, Lockheed, General Electric and Fairchild. The meeting brought out that while plans for a design were underway it was far from complete. Major complications arose over basic design of the camera. But it turned out that in fact there was quite a lot to be decided because the canceled program was going to use a spin-stabilized camera designed by Fairchild which had many advocates in the Air Force and Rand and in the agency. And I think the principal change that you and I made in the plan was a decision that we would go instead for a camera that was proposed by ITEC which required vehicle stabilization but would give us almost three times the resolution if it were successful. ITEC Corporation was a relatively new optical sciences firm formed by a group of scientists from the university research centers in the Boston area. ITEC's concept proposed a longer focal length lens for the camera and scanning within an earth-centered stabilized path. The decision to turn to this new design was agonizing for it meant moving from a relatively simple method of stabilization to one that was untried and technically more complicated. The advantages would be lower cost and much greater definition of intelligence targets. A panoramic camera takes a picture by rotating a lens through an angle like this. In this model we just took a picture through a large angle. In the original corona camera the lens after taking the panoramic picture would rotate back into position for the next picture like this. Now the trouble with that kind of action is that the high torques generated by the lens rotating in the two directions required us to put a counterbalancing mechanism in so that the action would not vibrate or shake the whole space platform the electrical and mechanical complexity of doing that of counterbalancing that high torque reduced the reliability of the early model. The second version of the camera the so-called J version was one in which we learned to separate the light part of the lens the upper part of the lens near the film from the heavy part of the lens and we would rotate the lens across in the way the early camera did and at the end of the picture taking cycle the heavy part of the lens would keep on moving and the light part would come back not generating much disturbance and the heavy part would then be mechanically connected to it and synchronized and another picture taken. On 16 April 1958 the final project proposal including the ITEC design was forwarded to the President's staff secretary with ARPA's review and approval the proposal was promptly approved although never in writing under the strict security rules surrounding the program work on the approved plans commenced immediately the camera optics were optimally designed utilizing then new computer graphic techniques the ITEC lens was a 24 inch focal length PETS file design early models were F5 speed and later ones developed to an F3 5 speed although a relatively conventional lens element design these were far from ordinary at the time the corona lenses were made they were equal in quality to any ever previously made lens blanks were taken from the finest available glasses and precision ground checked and mounted to bring out the highest performance then known to optical science the corona payload would ride the Thor Agena vehicle a hybrid made of a Thor intermediate range ballistic missile and a second stage Bell laboratories developed hustler engine later to be modified by Lockheed and known as Agena it's important to remember that at that point in time today's commonplace reliability of systems was unknown the Agena vehicle consists of a forward section which encompasses the camera and the recovery system behind that an electronics area which contains the horizon sensor, electronic power systems and so forth behind that the large tank and finally on the back the engine and the aphorac which contains the attitude control gas and actuated the contractor chosen for the Agena subsystem was Lockheed aircraft which also served as the prime contractor Lockheed had responsibility for integrating the payload operating the launch preparation facility and managing the subcontracts Agena was more than a means to place the camera in orbit the planned recovery sequence involved a series of controlled maneuvers by the Agena any one of which was critical for the mission would fail however Corona's most unique feature was its payload recovery system history would show that the crucial decade of the 1960s intelligence needs could not have been served by the state of readout technology at the time actual recovery from space was necessary it should be noted that both the man and unman U.S. space recovery programs were benefited considerably by the pioneering re-entry technology developed for Corona the subcontractor for the Corona recovery system was General Electric Company the model of the front end right here you see here the thrust cone retro rocket to get us out of orbit this device was connected with the Agena and when the Agena went into its downward attitude we were able to eject this from the Agena out of orbit once we got into that return trajectory the thrust cone here was ejected and this allowed the parachute to come out this is the parachute cover allowed the parachute to unfurl and that lifted the capsule out this is the capsule this portion with the heat shield this all happened after re-entry was thrown away after it did its job on re-entry and this is the recoverable capsule that we were after the mission of Corona necessitated a near polar orbit either by launching to the north or south however the launch site must be one which prevents danger for highly populated areas so the logical choice with a ballistic missile squadron already in place was Crook Air Force Base renamed Vandenberg Air Force Base in October 1958 under the highest priorities the preparations for test launches were completed by January 1959 however the first vehicle avoided on the launch pad due to inadvertent firing of the separation system success would not come easily to Corona the second Agena, Label Discoverer 1, was launched on 28th February 1959 and never heard from again well Ray, let's bring the back memories from pad 4 here in February of 1959 we launched Discoverer 1 for a time we thought it had achieved orbit but I think in later years that the people believed that it probably didn't make it and probably went in down around South Pole well you know the flaws at the launch base at that time were kind of skeptical that it made orbit and the same token meanwhile the uncertainties about Soviet missile capability mounted Vice President Nixon faced a belligerent Khrushchev in what came to be known as the kitchen debate there are some instances where you may be ahead of us for example in the development of your, of the thrust of your rockets for the investigation about our space there may be some instances for example color television where we're ahead of you but in order for both of us the third Agena launched a biomedical capsule on 13th April 1959 and achieved orbit but due to an incorrect setting of a timing device ejected within hours over the North Pole it came down in the snow near Spitzberg in Norway the capsule was never recovered at least by a U.S. team a few years later a movie called Ice Station Zebra resulted from speculations about the event problem after problem plagued the early Corona launch attempts these were truly the days of space pioneers where the solution to last month's failure only surfaced new problems for which engineering solutions must be founded and finding them meant little time to look for optimized solutions requiring long development times however the gravity of such events was not without lighter moment a prize example was a solution to securities requirement for an on-pad payload cover while design of a shroud was eventually completed the interim solution was prepared from ping pong balls brown paper and piano wire the test vehicle was what was then a high-speed sports car tried out down range on the Bayshore Freeway unfortunately the test was avoided by a speeding ticket for the test engineer and this design was phased out after one flight meanwhile concern about intelligence and our missile posture grew and became a major item of debate in the presidential election of 1959 my source of concern is a remark made by the president secretary Mr. McElroy about a month ago he said if the Russians build all the missiles that they capable of building and if we build all the missiles that we're planning to build then quite obviously the Soviet Union will enjoy an advantage in the missile area I would go under the assumption that they will build all they can I'm quite aware of what we are planning to build I therefore think that the president, however expert he may be has come to the wrong conclusion on the needs of defense the central intelligence agency's national estimate for guided missiles for the year 1959 contained footnotes by both the army and air force intelligence agencies taking issue with CIA's estimate of Soviet missile strength the discrepancies emphasize the need for hard intelligence the U-2 had improved knowledge of the Soviet Union but the critical questions went unanswered then on 10 August 1960 the diagnostic flight 13 was ready for launch at the time discoverer 13 was launched a number of major problems remained to be solved achieving an acceptable orbit operating the camera and in the all-important recovering of the payload film telemetry quickly revealed that 13 did achieve orbit and the initial positioning was correct 17th orbit, the recovery package ejected, retrofired and descended normal except for missing its intended impact point by 313 miles beyond the range of recovery aircraft 13's capsule splashed down near enough for water recovery for the first time ever man had orbited an object in space and recovered it according to plan the capsule carried no film but had proved the ability to do it and beat the Russians in their similar Sputnik 5 dog carrying capsule by just 9 days indeed corona had paved the way through its backup technology for splashdown recovery of the U.S. man in space program missions President Eisenhower proudly proclaimed discoverer 13 first returning space voyager history would show that much credit for the success was due to a new cold gas spin and despin technique applied first to discoverer 13 just 8 days after this first success discoverer 14 was launched it carried a 20 pound film payload discoverer 14 was a quick man from the start the satellite was on the verge of tumbling on the third orbit it was finally stabilized by expending precious gas force C-19s deployed in hopes of air snatching the capsule and the secret space dropout began the satellite recovery vehicle was ejected on the 17th pass this time the capsule deployed right in the ballpark aircraft from the 6593rd test squadron raced to the proper coordinate the first two attempts missed but on the third try the capsule was air snatched by pelican 9 adding still another first to corona's history aerial recovery although the initial photography was substantially lower in resolution than that from the U-2 it was of intelligence value this one mission yielded more photographic area coverage than the total of all U-2 missions over the soviet union more importantly the mission covered areas never previously reached and a new age of technical intelligence had begun meanwhile soviet party chairman khrushchev visited the united states an interesting sidelight is that his journey from san francisco to los angeles by train took him through a part of vandenberg air force base virtually within a mile of the corona launch complex while chairman khrushchev was sightseeing still another corona launch was being ready in the practice of the time the countdown was halted while trains passed to prevent unauthorized viewing of a launch launches were made during the window between trains while khrushchev pounded the table at the united nation our photo interpreters were busy evaluating the substance behind his boast today we hear a great deal about the soviet ss9 and ss11 icb young we know a great deal about these weapons in fact enough to make these very accurate models however much earlier in late 1950s our situation was very different indeed it was in that year that i first became involved with analysis on soviet weapons systems it was also in that year that three major things occurred first we obtained youtube photography of the soviet missile test facilities and learned the extent of that program secondly mr. khrushchev announced that the soviets had achieved an intercontinental ballistic missile capability third and most dramatic i believe was indeed the beginning of the space era well before corona the soviets put in orbit in the year 1957 sputnik 1 sputnik 1 was a dramatic illustration that the soviets indeed possessed the capability to launch a weapon against the united states the remaining question however was whether indeed such weapons were being deployed we could not provide an answer to that question this led rather directly to the famous missile gap debates that occurred during the presidential campaign in 1960 in fact in that same year corona was first successfully recovered that is the film of the soviet union was brought back to the united states and we could begin to provide answers by the mid 1960s we knew with great confidence the exact number of weapons of all types that were deployed in the soviet union it was this information which made it possible for us to start to consider strategic arms talks with the soviet union and indeed because of the high confidence that we knew the exact number of weapons this country entered those discussions and as you know they were successfully completed on 13 september 1960 discoverer 15 was sent along and soon proved the corona problems were still not yet solved although 15 apparently worked properly it re-entered at the wrong pitch attitude causing the capsule to fall outside the recovery zone it sank before a recovery ship could reach it discoverer 16 in october failed to achieve orbit discoverer 17 was launched in november of 1960 and seemed to be a mere perfect mission right up through successful air snatch except for one problem the film broke before any photographs were exposed then on 10 december success came again to corona discoverer 18 returned 39 pounds of film improved the effectiveness of an improved camera capacity and the more powerful a gena b launch vehicle slowly technology was emerging to correct each fault as it appeared for example mysterious aberrations began appearing on the film from time to time scientists soon established that it was the result of a buildup of static electrical charge coincidentally called corona although this phenomenon was well known its cause in a space environment was not known until it was accidentally duplicated during a series of component tests the culprit turned out to be the formulation used in certain rubber parts and once identified could be reformulated to eliminate the problem an earlier far more serious film problem was solved by eastern Kodak researchers who developed a new polyester base to replace the brittle weaker acetate film and again corona scored a technological first by employing the thinner base material and ushering in a new era of film technology polyester film development solved one of the major space reconnaissance problems 1960 the new film was being used on every flight the year 1961 was the time for the maturing of corona with each series of launches increasing sophistication was added discoverer 21 proved the feasibility of restarting the Agena engine in space a technique to prove useful to later corona and NASA missions then on 30 August 1961 the missions began to carry an improved camera system a mapping capability was developed re-entry programming debug and additional launch vehicle difficulties worked out slowly but surely the problems were solved but it often seemed that when one was laid to rest another rose to take its place many people referring to the program remember the large number of failures that preceded the final success in discoverer 14 in fact there were a large number of failures we had a launch attempt that was aborted on the pad we had a capsule that was impacted into the earth in the wrong area we had an unsuccessful launch where the vehicle did not achieve the proper velocity we had a capsule which was ejected from the vehicle but went off into a new orbit instead of going into the earth's atmosphere we had power failures we had thermal problems we had procedural problems and so forth while these were a lot of failures they were also the necessary development to get us to the successes that we eventually needed we for example did prove the booster we did prove the ground control system we did prove the orbital operations we proved the camera we proved the re-entry body and finally we proved the overall system but of course to all of us that work so closely with the program government and contractor alike we did not consider the program a real success until we returned the exposed film to Washington D.C. I think one of the important points that we can observe from the program is the tremendous dedication, resolve, and that's the purpose that the entire team had government agencies, the service, the industry all the way up and down the line to get this thing accomplished I don't think it could have been done in today's climate we probably wouldn't have been allowed to go beyond the sixth fair before the program would have been canceled rather than go 12 flights before we had the successful one on the 13th and that isn't to say that we didn't have our discouraging moments and our frustrations I remember some time along midstream I guess it was about the 8th or 9th flight where we didn't get it back and one of the members of the team held pined at one of our meetings that perhaps there was some fundamental reason why something couldn't come back from orbit maybe there was a fundamental technical point that was missed and maybe you could never get anything back from orbit which just goes to show you the direction of thought at the point of time that the midstream saw it didn't make too much difference and we went right along to the accomplishment and we also had a lot of fun with this incident later on when you have things back on our hands you know today when we've landed men on the moon several times and we're about to drop a lander on Mars and we've done so many other incredible things it's a little hard to believe or to get the feeling for 13 years ago and how relatively unsophisticated we were how little we knew about how to do all the intricate things that had to be done to make a space system work well we asked ourselves today after the fact why this program worked so well and particularly what the operating environment was like how we got along with other companies in the field how we got along with the government and they with us I think to understand why that worked so well you have to remember that we were all we were a small army in the first place and we were an army banded against a common enemy namely the apparent impossibility of doing what we were about to try to do it's really very difficult to convey to particularly to a young person today who has lived the last 10 or so years with all the space achievements that are so common it's difficult to realize that we were all operating in those days in a field in which we didn't really believe it could be done and we were just going to try and under those conditions the way in which a company works and a team works is really very different okay that should do it give it to Arnie with the beginning of 1962 the Discoverer series came to an end after 37 attempts the story was simply worn out with the improved record of success there were too many launches to suggest a continuing scientific program so beginning with the 38th launch on 18 April 1962 all Corona missions were announced as secret Air Force missions in the first two years only seven missions had returned filmed but what those yielded is an indication of what was in store most of the areas of vital interest had been covered some 25 million square miles and had yielded many times a number of images of all previous reconnaissance in history by now the most apparent limitation was the length of missions and the amount of recoverable film so an extensive R&D effort had produced a two-camera system known as Neural the Neural series produced more film coverage more importantly, literally added dimension by taking two photographs of the same area from slightly varying angles this allowed photo interpreters the advantage of looking at photographs very optically and thus allowing a third dimension and the ability to accurately measure heights this intelligence, along with that gathered by other means allowed CIA to put together highly detailed technical data on Soviet weapon systems thus we now knew how many were deployed and could define their capabilities the reliability of the intelligence community product improved quantitatively interestingly, this knowledge meant we need not overreact to conjectures about threats but rather expand our defense resources more realistically our own space capability was also growing by now no small part of our technological strength is coming from the development of corona itself for example, the boosting capacity of the first stage Thor vehicle was increased substantially by attaching a cluster of small solid propellant rockets this thrust augmented Thor, or TAC as it was called allowed heavier payloads and meant the camera systems would be improved even further the next step was development of a new series J camera system which had a significant advantage of carrying two recoverable buckets which meant that one launch could provide film while a satellite was still in position and then be directed to produce another run of photographs the J system and the improved launch capability plus all the development effort turned the recovery of capsules from an event to a routine operation by the time President John F Kennedy stood at the Berlin Wall we knew with confidence that we were unsurpassed militarily freedom is indivisible and when one man is enslaved, all are not free free men, wherever they may live a citizen is Berlin and therefore, as a free man I take pride in the word Ich bin ein Berliner in the 1960s, the corona capability continually improved an even more powerful Thorad booster was employed and the J1 camera gave rise to the J3 however, one can't leave the story of the J1 successes without mentioning its most spectacular failure mission number 1005 was launched on 27 April 1964 launch and insertion into orbit were uneventful then telemetry indicated a film break after partial completion and a power failure Vandenberg transmitted from other stations but ejection still did not occur a month later, radar sightings indicated the satellite had probably burned up on entering the atmosphere however, on July 7th, two farm employees in southwestern Venezuela found a battered, glimmering gold object a photographer from San Cristobal who photographed the object notified the American Embassy and the corona team was sent to purchase it from the Venezuelan government the event was dismissed as a minor NASA experiment gone astray by 1965, the rate of success was phenomenal on the average three or four recoveries were made every month the seven years of frustration and effort were paying off a mission in 1964 yielded four full days over target on each of its two buckets in 1965, this capacity was raised to five per bucket for a total mission of ten days coverage and by 1966, this had been more than doubled all phases of the operation were performed under strict security movements were made at times when they aroused the least interest and under maximum security control and sporting and processing the exposed film was assigned to the Air Force the highest priority was given to getting the film into the hands of interpreters the bulk of exposed film was rushed to west over Air Force base where special facilities were set up to expedite the processing under rigid quality control standards elaborate systems were handling and identifying each exposure were evolved assuring that no human error could preempt the intelligence to be gained no time went to waste yesterday's recovery was today's processing run in tomorrow's photogrammetry assignment at the National Photographic Interpretation Center the flow of substantive intelligence increased and the speed of information to users went from days and months to hours the quality of the results was well summarized off the record by President Johnson the President, speaking at a conference of educators on March 17, 1967 said that because of satellite reconnaissance, I know how many missiles the enemy has at one point, he added that the nation had spent 35 to 40 billion dollars for military and civilian space programs but that the benefits of satellite photography alone would justify 10 times as much expenditure what is interesting at that point in time was the effect of corona photography to the then current debate over whether the United States should deploy an anti-ballistic missile system corona intelligence proved the Soviets were deploying such a system and we took steps to meet the threat and urge the Russians to curb the arms race thanks to corona, the apprehension ushered in by Sputnik gave way to reasoned and affordable reaction in the first decade of the space age, corona had played a vital role not only had we achieved the ability to weigh the balance of power in the world correctly and differentiate the mock threat from the real one but we had completely revolutionized the intelligence process if new weapons were tested in hidden areas of the world or if troops moved or significant changes of any kind occurred we were no longer vulnerable to the vagaries of chance corona had made possible a new era of technical intelligence as a result, we were warned before the Soviets intervened in Czechoslovakia and successfully monitored preparation for the 1967 war in the Middle East we have proved that we are a good and reliable friend to those who seek peace and freedom we have shown that we can also be a formidable foe to those who reject the path of peace and those who seek to impose upon us or our allies the yoke of tyranny in 1967 the final evolution of the corona camera took place although the J-1 was performing almost perfectly it had been developed to the limit of its potential the J-3 was designed to eliminate vibration, improve resolution, and improve calibration data the sophistication for command response gave the J-3 much greater versatility the history of the J-3 improved the intelligence quality substantially and proved to be even more reliable than the excellent J-1 however the real test of the improvements can be seen in the evolution of image quality on the earliest corona missions, a target image of 25 foot resolution was all it was obtainable but as lenses, stability, and film technology improved the images resolved smaller and smaller detail until with the J-3 image resolution was down to 5 or 6 feet this quantum improvement significantly improved both the amount and quality of intelligence derived from the corona product then in 1968 tests proved the value of color in infrared imagery photographs from space could detect crop and environmental conditions of value to strategic intelligence and ushering in a new field of earth resources studies from space the impact on photographic interpretation was enormous program which I think would be worth recording here before the early 50s the central intelligence agency had no photographic intelligence activity at all we started with a handful of people and one of the great consequences of the program is the enormous rush of growth that it has created in our own photographic intelligence resources where now the National PI Center is probably the largest or one of the largest photo intelligence activities in the world certainly the largest in the West but when we started we had less than 13 people we had less than 800 square feet of floor space we had a budget of less than $100,000 a year here in the 1972 fall we have more than 1500 people dedicated to the exploitation of these products we have a budget each year which is pretty close to $30 million we have over 400,000 square feet of floor space and a program that is no way yet topped off it's steadily growing now little did we realize what was going to develop so quickly went on the 18th of August in 1960 this first satellite was successfully retrieved it flew for only one day it had 16, 17 passes eight of them over the Soviet Union and 20 pounds of film came back and with that film in hand we turned to and in less than seven days we had produced 130 pages of text we had a 1.5 million square miles of coverage of the Soviet Union this was the harbinger that warned us of what was coming and as we were steadily gearing up and trying to get ready for what was coming both in instrumentation and procedure and data handling products the film was flowing in by the time the program ended we were dealing with film that was coming in at the rate of 32,000 instead of 3600 linear feet per mission we had covered over 520 million square miles of real estate we had produced millions of pages of reporting and we were involved in all the major issues of our time all the ICBMs in the Soviet Union the complexes had been discovered for example by 1964 all their SAM sites, all their airfields all their nuclear weapons testing and storage sites all of their Y-class submarines, all their enigmatic problems we were right on top of these and we were involved in the major decision making of our time it was a tremendous demand upon the people in this center the 145th and final corona launch took place on 25 May 1972 corona had proved to be a remarkable investment the totality of corona's contribution to U.S. intelligence holdings on denied areas of the world and the U.S. space program in general is virtually unmeasurable what had begun as a desperate attempt to meet a sinister threat had succeeded beyond the wildest imaginings of the program's initiators the list of corona firsts is unparalleled the first recovered objects from orbit first to deliver intelligence information from a satellite first mapping from space first stereoptic pictures from space the first satellite to employ multiple re-entry vehicles and the first reconnaissance program to pass the 100 plus mission mark and not least the first photography from a satellite corona's 167 successful recoveries are more than the total of all other United States programs combined corona provided photographic coverage of over 500 million square nautical miles of the Earth's surface a dramatic achievement in itself but the true importance to national security came from the intelligence from lifting the curtain of secrecy which surrounded the Soviet Union and the People's Republic of China the contributions of corona between 1960 and 1972 can be summarized by saying it made it possible for the president in office to react wisely to crucial international situations at a point in time of critical balance between peace and war it was confidence in our intelligence that allowed the United States to enter into the strategic arms limitations treating there can be no doubt of the role of corona in history corona is now history it stands as an important point in time the first, the longest, and most successful of the nation's intelligence programs to date corona explored and conquered the unknowns of space reconnaissance and it opened the way for more sophisticated follow-on systems there were no elaborate facilities the work was done in a dairy farm building in Boston a grocery warehouse in Philadelphia and a skunk work section of a helicopter plant in Palo Alto, California the cost was modest and corona paid a huge dividend vital intelligence at an important point in time