Thanks for the reply, Kapil. Brief comments/updates inline below. > The root of the issues here come out to the choice and the reason for it made > at the preimplementation given two paths forward. ... We have different perspectives. In trying to determine the way forward from your comments, Benji and I developed an analysis of next steps. I introduce it below. > regarding rework. ... Unfortunately we have a number of disagreements. As I said before, I agree that rework is sometimes necessary in a review. We disagree on its acceptable frequency, its implications about process, and other topics. I'll pursue these further in a different time and forum. > all that said, i'm okay with this proceeding without rework inspite of my > concerns, given the service route is also updated (ie 3 conditionals), in the > hope that's its easy to refactor/remove if its a problem in the future. Benji and I talked about this. You have a different goal than we had in mind, and we think there might be an even better goal than what either of us had thought. Our goal was to keep the service from cluttering the environment--to keep the GUI away from the user in the common case. In this approach, nothing is ever broken even if a link to a hidden service is inadvertently revealed, because routes still work. You can also reveal and hide services on demand. We identified two downsides. First, there would be an opportunity for some surprise if a user found notifications or relations referring to a hidden service. This shouldn't happen, and if it did, nothing would break. Second, when you try to create a service, messages about existing names for a hidden service might be confusing. However, the client app would actually know about the hidden service, and we could write a custom error message if this proved to be a real problem. To do this, Benji had two conceptual tasks: - Hide services in the environment view. - Do not draw relations to hidden services in the environment view. That's what this branch does, along with various tests. You've asked for a different goal, to completely hide the service. That goal has one user advantage within the GUI, in that it reduces the possibility of surprise. However, it sets up expectations that are viral: any application that links to the GUI, such as Landscape, but also not link to the GUI for services that are hidden. Other alternatives start to look a lot like the "don't clutter the environment goal," above. It also involves more changes. I'll talk about the changes associated with this goal, given two possible implementation approaches, in a moment. Before I do so, I wanted to mention a third, alternative goal: keep the user from destroying the GUI unintentionally. Nothing is ever broken, and nothing is ever surprising, because we show the truth. While the GUI charm might somewhat clutter up the environment, users can move it to the side, and this placement will even be persistent soon. To accomplish this, we only need on change from trunk, conceptually: disable the service "destroy" button, with or without a message. This accomplishes the critical user goal with the absolute least code and the least opportunity for surprise. We advocate this as a way forward different from all the other ones discussed: redo the branch to radically simplify the goal and implementation. If we do pursue the second goal, to completely hide the service, we have identified two paths forward. First, we can continue keeping the changes in the view code. The failure mode for this approach--that is, the likely sort of errors we would introduce if we make an implementation mistake--is that a particular view might reveal something that is supposed to be hidden, and might additionally give a link that goes nowhere. Conceptually, we identify these tasks for this approach. (Already done) - Hide services in the environment view. - Do not draw relations to hidden services in the environment view. (Need to be done) - Reject routes to hidden services - Hide relations to hidden services in service page - Filter notifications (both relation errors and any other notification that refers to hidden service). Alternatively, we can implement this goal at the database level, as you envisioned. The failure mode for this approach is that a mistake might corrupt our data representing the juju environment. We identify these tasks for that approach. - Filter out hidden services from delta stream - Filter out relations to hidden services in delta stream - Filter out notifications to hidden services in delta stream - Filter out relations to hidden services in env.get_service callback - Filter out relations to hidden services in env.get_endpoints callback - Review env.destroy_service (what happens if you destroy a service in an existing relation?) In addition, for both approaches, we need to be concerned with applications that link to the GUI, such as Landscape. - Display code driven by annotations (e.g. from Landscape) needs to be vetted to make sure that links to hidden services are not presented (e.g. machine hosting gui needs reboot) - Other apps that might link to these services (e.g. Landscape) in the GUI need to either be aware of this logic or need to have a route that redirects to somewhere else with...explanation? If we had not already implemented the steps for the first approach, we would still prefer it. In sum, we have three possible goals. We could keep the user from destroying the GUI charm by simply disabling that functionality. We could keep the GUI service from cluttering the environment, as we do now. Or we could completely hide the service's existence. We propose that the first goal is the best one for the user. How do you feel? Is the new goal appealing to you?