Re: GBeans: Saving Changes
I'm listening to this discussion and trying to make sense of it so that I can understand how it will affect our users. Keep in mind that I'm still grasping at the fundamentals of Geronimo and G-beans so this may be off in the weeds (and for which I will apologize for right now). As I think David Jencks mentioned earlier, are think there are different types of configuration data? Can we list some of the specific types of configuration items that we are talking about and group them? Perhaps that can simplify the problem. Here's my attempt: First, there is "configuration" which affects the structure of the solution itself (let's call it "solution configuration") ... such as changing the access protocol, changing the J2EE container, changing the security service, the persistent store, etc These are all changes that have substantial impact on the nature and behavior of the server. These are things that I would expect of somebody that is building a complete solution to be concerned with and I don't think it would be a problem if the changes were "maven-like" and required creating a new bundle (ie. not hosted in the admin console for runtime changes). Second, there is "configuration" which affects the behavior of the solution but not the nature of it (let's call this "server configuration"). These are more minor changes such as changing ports, hostnames, thread pool sizes, etc... This is standard end user configuration and items that I would expect an end user that is running a solution to have to "tweak" on a regular basis. These are types of configuration changes where I think it would be useful to be able to export and then later import the configuration for another server and that should be persisted apart from the Gbeans. This configuration may even include the set of deployed applications for the server. If we consider these items as being fundamentally different types of configuration with different users then I think it might simplify the problem. The "server configuration" changes should be available via the admin console and should not impact any G-Bean configuration as I understand it. The "solution configuration" would potentially affect the creation of and dependencies between Gbeans and would not necessarily require a WYSIWYG mechanism for change such as an admin console. Of course there will always be items in the "gray" area that are somewhere between these or may need to be changed by both types of users. Items in the "gray" area could be addressed on an individual basis such that it would not necessarily require mutable bundles (such as by defining both HTTP and HTTPS connectors and enabling or disabling as appropriate for the configuration). One final question I'll toss out (and possibly show my ignorance ... but at least I'll learn the answer :-) ) ... Aren't the applications that are deployed themselves represented by Gbeans in the bundle and therefore the bundle is already mutable in that sense? I read an article in JAX that indicated this was the case ( http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ). Is that correct or was the author mistaken? Aaron Mulder wrote: We're making progress! :) On Tue, 26 Jul 2005, Jeremy Boynes wrote: First caveat - o/a/g/Server is too monolithic which is contributing factor to these discussions. The reasons why this is a problem and how to start to fix it have been discussed elsewhere. True, though there are certain advantages too (like the ability to start and stop all that stuff with one command). Anyway, that's another topic. Second caveat, change through the web console is one use case. It applies to small installations (desktop, single server) but is less applicable to larger installations, say with 10 servers. It also does not apply to "headless" servers which may not be running a web container at all. Agreed. I have two I've given some thought to although they're not fully thought out - but hey, we're brainstorming right? Yes. Of the two, I like option 5 more -- and more than all the UUID-based options. I'm not sure the mutability needs to be reflected in the configuration name, though -- couldn't we have non-name properties for the version and mutability? That way the start/stop command would be the same and so on. You would refer to a prerequisite by providing the name and version range separately, and perhaps even indicating explicitly whether you're willing to depend on a mutable version. If you provide nothing but the name, that implies "any version will do". I'd propose we add a tool that can export one or more configurations named on the command line (or all current configs) and optionally: - mark them immutable - assign them a specific version or UUID - update any references between exported modules to use the new version number or UUID - include an explicit list of all their repository references if
Re: GBeans: Saving Changes
I really like this model and explanation and wonder just how soon we can make it a reality. Last fall I thought we needed the ability to add gbeans to running configurations so you could add datasources, queues, etc to the server while you were getting ready to deploy an app, using an admin console (in fact an earlier version of the one just donated by IBM). However, I think there's a better way to do this, namely, instead of adding bits to the app server to make the environment ready for the app, add bits of app server to the application so it brings what it needs along with itself. Right now we can do this with plain gbeans in all components (such as for security, corba, and web connectors), and resource adapters in app clients. I'm planning the ability to add at least entire resource adapter configurations into other module types, and considering adding the ability to deploy additional complete j2ee modules just using the vendor plan. I can imagine a bit of a ui that analyzes the configurations present in a server (i.e. a bunch of deployed configurations) and your application and shows you what is unresolved in the application, and guides you through either adding more prebuild configs to your server or adding additional stuff into your application so everything is pre-resolved before you try to deploy for the first time. I think with this point of view and possibly with such tools most of the need to add gbeans to running configurations goes away. As for the question of changing and saving gbean attributes in a running configuration, I'm not sure what to think. It seems like an interpreted vs compiled language debate. Right now our compiler is decidedly inconvenient for a rapid change cycle: I'm not sure how much faster it would need to get before it seemed like a more reasonable alternative to live changes. thanks david jencks On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote: I'd ask you to set aside traditional thinking and try this out for a bit. When you write code, you edit a couple of source files, compile it, fix the typos, build a jar, test it, decide its good enough and commit the change. After doing this a few times you decide its good enough and do a release, taking the jar file you built and saving for posterity. You then do it all over again. If you're doing this with Maven, it spells out the difference between the jar you are working with (a SNAPSHOT) and the jar you release (something with a version number). Sound familiar? In a large production environment you do the same kind of thing with system configurations. You set up a system the way you want, check that it works, beat the snot out of it (aka stress testing or benchmarking), see how/when it falls over, tweak the config and repeat until it you're happy, then document it, have someone else try the change in your staging environment, check it still works, then beg the change control board to let you move it to production at 3AM on a Sunday morning. You then cross your fingers and hope it really works. A bit different from changing things on a desktop machine or the box that runs the family website, but not unrealistic and the problem the architecture was trying to simplify. [[ to avoid a disgression, is Geronimo ready for this? Who knows; in the end the people doing such things factor in the risks associated with any software no matter how mature and they will make up their own minds ]] The idea behind the configuration bundles is that they are pre-wired sets of closely coupled components that co-ordinate to perform a specific task. A single bundle is *not* meant to represent the entire system assembly - the current o/a/g/Server is an abberation caused by problems in the classloader model (described elsewhere) not example of best practice. The purpose of a bundle is to allow a knowledgable person to, for example, pre-wire a web container in a way that allows other people to use it just by defining a few characteristics. So, for example, someone can go to a repository and find, for example, a pre-wired version of a Jetty bundle pre-configured for 100 concurrent users at 95% static content with a typical dynamic reponse time of 500ms when running on an Acme-4000 Linux machine. So why does this need to be immutable? Because if you are pulling these things from a catalog then you need to know that you're going to get what you expect and not some version that someone happened to tweak but just forgot to change the name. It would be like having several jar files out there called log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW one reason bundles are JAR files is because it's dead easy to sign them so that you can tell if they have been tweaked. Now, just as in the code development example I gave at the top, these kind of pre-packaged bundles are also going to go through a development process. One reason we didn't
Re: GBeans: Saving Changes
I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export myconfig-1.3.1.jar. Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts myconfig-1.3.1.jar to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the interchange format to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. I'll grant you I could download your configuration and then change it and then blame you if it doesn't work. But I already said I don't mind adding a flag of some sort. And really, what are the odds that a configuration is going to be 100% perfect? What if the web configuration is totally groovy but aimed at a bigger box so you want to tone down the accept thread pool? What if you want to change ports? What if you prefer Jikes? If you must take it entirely without alteration or not at all, I don't think that will be worth so much. As far as the volume of stuff in a configuration, we can think of some way to disentangle class loaders from configurations. But we have (in my poor estimation) probably hundreds of GBeans in a server today, and I don't think it makes sense to have tens or hundreds of configurations. That just means that if you want to disable some feature, you have to run loads of commands instead of one. And if you want to download from a catalog, you have a lot more individual stuff to download. It might be useful to separate EJB out from Web and J2EE foundation, but it doesn't bother me all that much -- we already have JMS and JDBC separate, which is a fine start. Not a big deal to me either way. I totally agree with David that it would be great to be able to deploy more bits as parts of an application. I think it's pretty desirable to be able to deploy connectors as part of an application, so you can bundle your DB pool or JMS destinations with your app. However, I don't at all think it makes sense to claim that replaces the ability to adjust server configuration at runtime, and I don't believe that it makes sense to actually bundle web connectors as part of an application. If nothing else, what happens if you have two applications that are both going to run via an AJP connection on port 8009? Which gets the connector? What if one app deploys HTTP on 8080 and another deploys HTTPS on 8080? What if you have developers who prepare applications, and administrators who do server administration? Does it make sense to require that admins have the skills and tools to alter the application plans (potentially damaging the plans that just passed QA)? In any case, to address the compiled vs interpreted bit, if your vision of management is that you must always edit a config file and then run a tool on the config file to replace the old state of the server with the new state, and the web console will always be read-only, I have to respectfully disagree (no matter how fast the tool runs). Thanks, Aaron P.S. I think we should ultimately separate some goals from implementation and agree on things like would be nice to have portable format for exchanging configurations, with ability to bundle one or more in a JAR and sign it and would be nice to be able to deploy connectors with apps. It seems to be the implications we disagree on more than the fundamental goals. On Tue, 26 Jul 2005, David Jencks wrote: I really like this model and explanation and wonder just how soon we can make it a reality. Last fall I thought we needed the ability to add gbeans to running configurations so you could add datasources, queues, etc to the server while you were getting ready to deploy an app, using an admin console (in fact an earlier version of the one just donated by IBM). However, I think there's a better way to do this, namely, instead of adding bits to the app server to make the environment ready for the app, add bits of app server to the application so it brings what it needs along with itself. Right now we can do this with plain gbeans in all components (such as for security, corba,
Re: GBeans: Saving Changes
Aaron Mulder wrote: I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export myconfig-1.3.1.jar. Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts myconfig-1.3.1.jar to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the interchange format to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. You alude to the problem yourself without realizing it. We have an example of the problem right now with our build system and its use of SNAPSHOT jars. SNAPSHOTs are mutable. Their content varies over time based on whatever happened to be in the source tree when they were built. If you have a SNAPSHOT artifactId you won't know from one build to another that you are using the same code. To the person developing that artifact, that it is a SNAPSHOT doesn't matter - it's output work product to them, what they are using is the source tree. However, to the person using the library it does matter. If they rely on a SNAPSHOT published to a repo they can't rely on getting the same code each time. If they need stability they need to use an explicit version. If the publisher publishes two different codebases under the same version number then, to use your phrasing, they're an idiot and as a user you start looking for alternatives. In other words, you want released artifacts to be immutable and versioned. To have a consistent release we can't use mutable SNAPSHOTS and we (primarily John) are going through and replacing them with immutable versions. Putting this in the configuration context, when you start modifying a configuration you are developing it - you're tweaking it to do what you want. This is not a problem for you. However, it is a problem for things that use that configuration and have certain expectations on its behaviour as it is now doing what you want and not what it advertised that it could do. There are things in the system that use your configuration - the config builders and the applications that they build are two examples. If you mutate the Server configuration from using Jetty to using Tomcat, an application that was built against that configuration with the assumption that it was Jetty will no longer work. The HTTP connector example we are so fond of is a bad one as nothing uses that bundle - it is a user of other bundles, dispatching requests to them but nothing actually references it. You can mutate it to your heart's content and nothing will notice. As an alternative, consider an example where an application contains a message-link that uses a queue. The application builder can look at the server configuration, see that there is no queue there and decide that it should define one in the application bundle. That bundle can be moved to any instance running that server configuration and will run quite happily as it is taking its queue along with it. However, if the server configuration is mutated on some instances so that it has a queue you now have a conflict: two queues, one from the mutated server, one from the application. Or if the configuration is mutated to use a different message provider then it may not work at all. The challenge we face is finding a balance between the things that can mutate that no-one will notice and things that should be immutable so that they can reliably be used by others. -- Jeremy
Re: GBeans: Saving Changes
FYI, I'm considering this a discussion on our long-term policy. In the immediate future, I'm planning to go ahead with mutable configurations to support the desired functionality in the web console. I'm definitely open to revising that when the time comes and we have a more comprehensive strategy around this. Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export myconfig-1.3.1.jar. Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts myconfig-1.3.1.jar to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the interchange format to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. You alude to the problem yourself without realizing it. We have an example of the problem right now with our build system and its use of SNAPSHOT jars. SNAPSHOTs are mutable. Their content varies over time based on whatever happened to be in the source tree when they were built. If you have a SNAPSHOT artifactId you won't know from one build to another that you are using the same code. To the person developing that artifact, that it is a SNAPSHOT doesn't matter - it's output work product to them, what they are using is the source tree. However, to the person using the library it does matter. If they rely on a SNAPSHOT published to a repo they can't rely on getting the same code each time. If they need stability they need to use an explicit version. If the publisher publishes two different codebases under the same version number then, to use your phrasing, they're an idiot and as a user you start looking for alternatives. In other words, you want released artifacts to be immutable and versioned. To have a consistent release we can't use mutable SNAPSHOTS and we (primarily John) are going through and replacing them with immutable versions. Putting this in the configuration context, when you start modifying a configuration you are developing it - you're tweaking it to do what you want. This is not a problem for you. However, it is a problem for things that use that configuration and have certain expectations on its behaviour as it is now doing what you want and not what it advertised that it could do. There are things in the system that use your configuration - the config builders and the applications that they build are two examples. If you mutate the Server configuration from using Jetty to using Tomcat, an application that was built against that configuration with the assumption that it was Jetty will no longer work. The HTTP connector example we are so fond of is a bad one as nothing uses that bundle - it is a user of other bundles, dispatching requests to them but nothing actually references it. You can mutate it to your heart's content and nothing will notice. As an alternative, consider an example where an application contains a message-link that uses a queue. The application builder can look at the server configuration, see that there is no queue there and decide that it should define one in the application bundle. That bundle can be moved to any instance running that server configuration and will run quite happily as it is taking its queue along with it. However, if the server configuration is mutated on some instances so that it has a queue you now have a conflict: two queues, one from the mutated server, one from the application. Or if the configuration is mutated to use a different message provider then it may not work at all. The challenge we face is finding a balance between the things that can mutate that no-one will notice and things that should be immutable so that they can reliably be used by others. -- Jeremy
Re: GBeans: Saving Changes
there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). thanks david jencks On Jul 26, 2005, at 2:18 PM, Aaron Mulder wrote: FYI, I'm considering this a discussion on our long-term policy. In the immediate future, I'm planning to go ahead with mutable configurations to support the desired functionality in the web console. I'm definitely open to revising that when the time comes and we have a more comprehensive strategy around this. Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: I don't understand why Jeremy's vision is incompatible with altering configurations on the fly. That is to say, you change and change and change, and when it's right, you (sign and) export myconfig-1.3.1.jar. Perhaps that includes a single configuration (web container). Perhaps it contains several (J2EE server in a box, ready to apply to nodes in a cluster). If anyone else posts myconfig-1.3.1.jar to your download catalog, then either 1) they're an idiot (just like if I posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not signed with your certificate and can be recognized as a forgery. If we package configurations in JARs (and we haven't defined the interchange format to move configurations between servers / config stores but a JAR certainly seems reasonable), then they can be signed using the same tools that are normally avialable. Having immutable configurations does not affect these issues. I can name and version my configuration the same as you do even if they were both totally unchanged at runtime. Without some sense and/or signatures, there's nothing to prevent anything from conflicting. Just like we could post an updated set of M4 QA JARs today with the same name but different content. You alude to the problem yourself without realizing it. We have an example of the problem right now with our build system and its use of SNAPSHOT jars. SNAPSHOTs are mutable. Their content varies over time based on whatever happened to be in the source tree when they were built. If you have a SNAPSHOT artifactId you won't know from one build to another that you are using the same code. To the person developing that artifact, that it is a SNAPSHOT doesn't matter - it's output work product to them, what they are using is the source tree. However, to the person using the library it does matter. If they rely on a SNAPSHOT published to a repo they can't rely on getting the same code each time. If they need stability they need to use an explicit version. If the publisher publishes two different codebases under the same version number then, to use your phrasing, they're an idiot and as a user you start looking for alternatives. In other words, you want released artifacts to be immutable and versioned. To have a consistent release we can't use mutable SNAPSHOTS and we (primarily John) are going through and replacing them with immutable versions. Putting this in the configuration context, when you start modifying a configuration you are developing it - you're tweaking it to do what you want. This is not a problem for you. However, it is a problem for things that use that configuration and have certain expectations on its behaviour as it is now doing what you want and not what it advertised that it could do. There are things in the system that use your configuration - the config builders and the applications that they build are two examples. If you mutate the Server configuration from using Jetty to using Tomcat, an application that was built against that configuration with the assumption that it was Jetty will no longer work. The HTTP connector example we are so fond of is a bad one as nothing uses that bundle - it is a user of other bundles, dispatching requests to them but nothing actually references it. You can mutate it to your heart's content and nothing will notice. As an alternative, consider an example where an application contains a message-link that uses a queue. The application builder can look at the server configuration, see that there is no queue there and decide that it should define one in the application bundle. That bundle can be moved to any
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
Re: GBeans: Saving Changes
Aaron Mulder wrote: Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Implementation: you set the magic enabled attribute causing the disabled bean to be started. New value of the property is saved in the database[1]. This is already possible. No modification to the o/a/g/Server configuration is required. Use case: You want to add a second HTTP connector. On the console you fill in a form describing the usage pattern of the new interface Implementation: using knowledge of the container in use and data from the form the console selects a suitable connector configuration from its catalog and adds it into the list of running configurations. No modification to the o/a/g/Server configuration is required. This is already possible with the degree of sophistication varying based on how the console locates the template configuration; a rudimentary implementation could just be code in the console (which IIRC is how JMS queues get added) Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console, fill out a form, and the GBean property is changed to use the correct password. Implementation: property value is saved in the database No modification to the o/a/g/Server configuration is required. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. [1] Database in this case is the dump of persistent attribute values that is currently held inside the config store. This implementation has problems (like no way to merge in modified values when a new version of a configuration is installed) but those are a separate discussion. -- Jeremy
Re: GBeans: Saving Changes
+1 for adding support for adding services to and removing services from a configuration On Jul 26, 2005, at 2:40 PM, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I don't think there is any way to avoid it in the current design. I'm not really sure how the current configuration saving works. Simple. In doStop of the configuration we package up the current configuration state and then tell the configuration store, the one from which the configuration was originally loaded, to update the configuration. The local cofinguration store simply, creates a new serilized file in the configuration save.ser. There is only one save version, so you could conceivably rollback to the original saved state, but not to a previous revision. Of course we have no rollback logic anywhere in the current code base. -dain
Re: GBeans: Saving Changes
David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter the configuration based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified current state, and it just happens that future server starts will use that current state (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- revert to factory default settings. Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
Re: GBeans: Saving Changes
BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter the configuration based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified current state, and it just happens that future server starts will use that current state (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- revert to factory default settings. Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/ Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just for this. Aaron
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the disabled gbean approach would work just as well, and, if not, if the application centered deployment idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying standalone admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter the configuration based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified current state, and it just happens that future server starts will use that current state (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- revert to factory default settings. Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console, fill out a form, and the GBean property is changed to use the correct password. As for your implementation thoughts, I thought this is essentially what was implemented -- that saved state was saved to a different place than original state. I do not think we need the scope creep of creating another database just
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote: Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Great. Before we jump into adding gbeans to a running configuration, can we please think about whether the disabled gbean approach would work just as well, and, if not, if the application centered deployment idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying standalone admin objects at all, whatever configuration they go into. RE disabled GBeans (blanks): The counter-example I gave in JIRA was security realms, which may use any number of LoginModules. It doesn't make sense to me to add enough blanks that you're sure no one would ever want to add more than that, nor to require that someone writing a new plan for their own purposes add enough blanks to accomodate future changes via the web console. What number would you tell them? 10? 5? RE app-centric deployment: And again, I believe there are cases where server administrators will be configuring the services in the server, and will not have the skills or tools to alter embedded XML files in the application configuration. This is more realistic for web listen ports, security realms, databases (where devs may not have prod DB password) or J2CA connections to back-end services than for admin objects (which I admit could often be best packaged with an application). Even without the administrator vs. developer issue, imagine staging your application from dev to test to production, where each server has connections to different databases and back-end services. It would be much nicer to put that configuration in the app server, so the application itself can be totally unchanged when it's migrated between environments. The application says I use a data source called 'DB2', and the server provides the data source pointing to a specific database, different in each of the 3 environments. I do like the *ability* to deploy data sources with an app -- just not making it the only options. Aaron
Re: GBeans: Saving Changes
Aaron Mulder wrote: Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Almost but not quite. The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. Where we still seem to disagree is on whether structural changes to the bundle are a good idea. So far I haven't seen any solution that allows this and addresses the technical problems raised above and don't think we should go down this route until we have consensus. -- Jeremy
Re: GBeans: Saving Changes
How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? -dain On Jul 26, 2005, at 3:23 PM, David Jencks wrote: On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the disabled gbean approach would work just as well, and, if not, if the application centered deployment idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying standalone admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter the configuration based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified current state, and it just happens that future server starts will use that current state (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- revert to factory default settings. Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/ Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more thought and a clear upgrade path to whatever we decide we want to do long-term. Still, this seems more reasonable to me than (1). Use case: server ships with HTTPS pointing to a self-signed cert. You want to point it to a real cert, which requires the server to use a password different than secret. You go to the console,
Re: GBeans: Saving Changes
Dain Sundstrom wrote: How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? I'm not a great fan of the disabled component option either - I just used it because Aaron's example referred to a disabled connector. Having said that, there is a big difference between a disabled service and an absent service - you know that is it there and hence can refer to it. It becomes a placeholder. -- Jeremy
Re: GBeans: Saving Changes
FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support build the bundle on a master node in a cluster and then automatically push it to worker nodes and how to support features that no other app server has. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same current state that the server would use if it started. Otherwise, what's the point? This shouldn't be at all hard to fix if that's not the way it works today. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. I think this is a fine candidate for later refactoring. Aaron Where we still seem to disagree is on whether structural changes to the bundle are a good idea. So far I haven't seen any solution that allows this and addresses the technical problems raised above and don't think we should go down this route until we have consensus.
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote: If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. We have this problem regardless. Any mutation in the environment or configuration state can cause a service to not start. For example, if a users moves an important directory, or changes a service attribute to point to a new directory. The proposed change does not solve that problem but it doesn't cause that problem either. When someone comes up with a solution to this problem, we can change the console also. It is *soft*ware after all. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. The command line maven tool will load the current state from the server configuration store. If the maven plugin doesn't do that I would consider that a bug. -dain
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:43 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Great. Before we jump into adding gbeans to a running configuration, can we please think about whether the disabled gbean approach would work just as well, and, if not, if the application centered deployment idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying standalone admin objects at all, whatever configuration they go into. RE disabled GBeans (blanks): The counter-example I gave in JIRA was security realms, which may use any number of LoginModules. It doesn't make sense to me to add enough blanks that you're sure no one would ever want to add more than that, nor to require that someone writing a new plan for their own purposes add enough blanks to accomodate future changes via the web console. What number would you tell them? 10? 5? I think this is a prime example of where you should use app-centric deployment, i.e. put the security gbeans in the application. RE app-centric deployment: And again, I believe there are cases where server administrators will be configuring the services in the server, and will not have the skills or tools to alter embedded XML files in the application configuration. This is more realistic for web listen ports, security realms, databases (where devs may not have prod DB password) or J2CA connections to back-end services than for admin objects (which I admit could often be best packaged with an application). Even without the administrator vs. developer issue, imagine staging your application from dev to test to production, where each server has connections to different databases and back-end services. It would be much nicer to put that configuration in the app server, so the application itself can be totally unchanged when it's migrated between environments. The application says I use a data source called 'DB2', and the server provides the data source pointing to a specific database, different in each of the 3 environments. I'd think you'd want to have a compatibility-layer configuration including all the app specific stuff that needs to be different for each server. Each environment would get its own compatibility layer, exposing the same stuff to the application. I do like the *ability* to deploy data sources with an app -- just not making it the only options. I think we might be missing the point to some extent. We all want geronimo to be easy to use and configure, and scale well to really large deployments. Obviously we need ways to deploy applications so they run, and all their needs are met. The questions seem to me to be when (deploy or runtime) and where (which configuration). Other servers AFAIK tend to have monolithic server configurations and limited application configuration, and a lot of server configuration may have to be done at runtime. What if we take a step back from what we are used to doing and think if there is a better way. One point of view is that if you have to change something on your running server, your deployment tools weren't good enough: they should be good enough so when you deploy, everything is there, and it works. This is sort of like type safety in compiled languages: by the time you get to running, the system has already eliminated many classes of errors. thanks david jencks Aaron
Re: GBeans: Saving Changes
On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote: How is enabling and subsequently configuring a service is substantially different then just adding a new one? Simmilary, why is disabling a service substantially different then removing it? My idea is that live changes should only affect attribute values, not reference patterns. So, a disabled gbean will still be (potentially) hooked up to the correct other gbeans, and will have some sort of attribute values that might possibly be useful. An entirely new gbean won't have these features. david jencks -dain On Jul 26, 2005, at 3:23 PM, David Jencks wrote: On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote: BTW this is already has a JIRA entry GERONIMO-400. I added this almost a year ago. No wonder I couldn't find it. I thought I added it :-) Now that how saving configuration works has been explained so even I can understand it, I don't have any problem in saving configuration locally. I can even imagine a tool to merge a local state with a configuration to produce a new configuration (with a different version number or name). Before we jump into adding gbeans to a running configuration, can we please think about whether the disabled gbean approach would work just as well, and, if not, if the application centered deployment idea would work better. IIRC the original motivation behind GERONIMO-400 was to put the admin objects you can add by the admin portal into the original jms configuration rather than making a separate configuration per queue/topic. If you have the opportunity to add the admin objects while you are deploying your app that will use them, I can't actually see any reason to support deploying standalone admin objects at all, whatever configuration they go into. thanks david jencks -dain On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote: David, I believe we need to be able to make this kind of change to a running server. The commercial products we're (at least in theory) competing with all support making this kind of change through their management console, though for certain types of changes a server restart is required. Changing the port you're using to connect to the console at runtime would be a little weird, but I'm strongly opposed to requiring someone to locate, modify, and redeploy the o/a/g/Server plan in order to make any change at all. Jeremy, I agree that changing an attribute value does not need to alter the configuration based on what is implemented today. IIUC, when you alter a GBean, a new set of config info is written to a separate file, and next time the configuration is loaded that file is read and the new value kicks in instead of the original value. So you have both the unaltered original configuration and the modified current state, and it just happens that future server starts will use that current state (though I suppose we could provide some sort of command to revert a configuration to its original state). That would actually be a kind of cool option in the console -- revert to factory default settings. Maybe I've been casting this entire discussion in the wrong way. Both changes to GBean properties and adds/removes of GBeans can be accomplished by adjusting the current state saved *in addition to* the original state -- so at the end of the day, we're not really altering the configuration, we're preserving the original configuration and altering our current state for the configuration. Perhaps we're in violent agreement. :) Aaron On Tue, 26 Jul 2005, David Jencks wrote: IMO both of these are much better done as part of the offline deployment process well before the configuration gets anywhere near a running server. Both of these are reasonable things to do, but again IMO not on a running server. I'm not really sure how the current configuration saving works. thanks david jencks On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote: On Tue, 26 Jul 2005, David Jencks wrote: there are at least 2 aspects to mutable configurations. 1. adding/ removing gbeans. I don't think there is a valid use case for this and don't think we should support it, ever. I don't think we should allow changing reference patterns either for essentially the same reasons. Use case: Server ships with HTTPS or AJP disabled. You want to enable it. You go to the console, fill in a form, click a button, it is now running. Under the covers, a connector GBean has been added to the o/a/g/Server Configuration. 2. changing attribute values on pre-existing gbeans. To me this is less clear. I'm not thrilled with the idea of changing the content of a configuration jar: I'd prefer to see local modifications saved in a local database outside the supplied configurations. I can see how you would want to play with a running server till you like it, then save and seal a configuration, but I'm reluctant to allow this without more
Re: GBeans: Saving Changes
Aaron Mulder wrote: FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support build the bundle on a master node in a cluster and then automatically push it to worker nodes and how to support features that no other app server has. Yep, that was one of the design goals when we started on this, er, two years ago. And there are other servers that do this kind of thing, WebSphere-ND is one. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. None of these interfere with 1-server support. There's just no need to break N-server support that is already there whilst doing so, especially when people have already stated to talk about adding clustering support. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. No one is advocating not making any changes so please do not over dramatize the discussion. What doesn't make sense is breaking features we have now for a solution we have already identified has problems, planning on a refactoring say within 6 months to a mode that can't use the interim solution as there is no guarantee of consistency. Why not start the discussion on how to impove what we have e.g. by providing bundle level properties, by separating out management properties into an human-readable database rather than burying them in the config store, by separating manageable attributes from unmanageable ones used for wiring purposes, by adding bundle metadata? That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. That is a different problem - we didn't break your EJB, it failed because it could not connect to the database. The same problem would occur if the DBA changed the database password or took it down for maintenance. This is just a regular operational problem. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same current state that the server would use if it started. Otherwise, what's the point? This shouldn't be at all hard to fix if that's not the way it works today. Because it may be on a different machine, for example. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. I think this is a fine candidate for later refactoring. Perhaps we should look at it now - it may make things simpler. Well, after M4 of course :-) -- Jeremy
Re: GBeans: Saving Changes
Dain Sundstrom wrote: On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote: If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. We have this problem regardless. Any mutation in the environment or configuration state can cause a service to not start. For example, if a users moves an important directory, or changes a service attribute to point to a new directory. The proposed change does not solve that problem but it doesn't cause that problem either. When someone comes up with a solution to this problem, we can change the console also. It is *soft*ware after all. There's a difference between not starting and not present. If something doesn't start because of environmental issues then you have an operational problem. If the server says it offers some services (e.g. a Jetty container) but has incompatibly mutated (e.g. into a Tomcat container) then you have a much bigger set of problems. The immutablity is there to solve that. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. The command line maven tool will load the current state from the server configuration store. If the maven plugin doesn't do that I would consider that a bug. No, we've been there already (ApacheCon last year). That is coupling offline deployment to an instance of the online system rather than allowing it to use the advertised target environment. The current command line tool in offline mode loads the state from its internal config store which just happens to point to the same directory. Ironically, this would be fine if configurations were immutable. The plugin loads bundles as artifacts from the local maven repo - which is fine as they are immutable - automatically giving us the ability to publish bundles online. -- Jeremy
Re: GBeans: Saving Changes
On Tue, 26 Jul 2005, David Jencks wrote: I think this is a prime example of where you should use app-centric deployment, i.e. put the security gbeans in the application. What if your developers are not trusted with the production database or LDAP accounts? Are you arguing that your application deployment information should need to be changed between final test and production? I think it's a pretty important feature to be able to have an unaltered EAR going from test to prod. I'd think you'd want to have a compatibility-layer configuration including all the app specific stuff that needs to be different for each server. Each environment would get its own compatibility layer, exposing the same stuff to the application. Okay, now you're arguing that app-centric deployment does not always work, which I would obviously agree with. So what if you want to change the compatibility layer? Wouldn't it be nice if you could do that in the web console instead of be writing deployment plans and redeploying them? This is what ease of use is all about to me. We can totally support changing things on the fly in the web console. Why not give people that option? Other servers AFAIK tend to have monolithic server configurations and limited application configuration, and a lot of server configuration may have to be done at runtime. What if we take a step back from what we are used to doing and think if there is a better way. Again, I support this 100% as an option. I just don't believe it is the *only* option. I think each approach has its advantages, and different situations would benefit from each. I believe we should support both. Aaron One point of view is that if you have to change something on your running server, your deployment tools weren't good enough: they should be good enough so when you deploy, everything is there, and it works. This is sort of like type safety in compiled languages: by the time you get to running, the system has already eliminated many classes of errors.
Re: GBeans: Saving Changes
Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? Thanks, Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support build the bundle on a master node in a cluster and then automatically push it to worker nodes and how to support features that no other app server has. Yep, that was one of the design goals when we started on this, er, two years ago. And there are other servers that do this kind of thing, WebSphere-ND is one. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. None of these interfere with 1-server support. There's just no need to break N-server support that is already there whilst doing so, especially when people have already stated to talk about adding clustering support. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. No one is advocating not making any changes so please do not over dramatize the discussion. What doesn't make sense is breaking features we have now for a solution we have already identified has problems, planning on a refactoring say within 6 months to a mode that can't use the interim solution as there is no guarantee of consistency. Why not start the discussion on how to impove what we have e.g. by providing bundle level properties, by separating out management properties into an human-readable database rather than burying them in the config store, by separating manageable attributes from unmanageable ones used for wiring purposes, by adding bundle metadata? That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. That is a different problem - we didn't break your EJB, it failed because it could not connect to the database. The same problem would occur if the DBA changed the database password or took it down for maintenance. This is just a regular operational problem. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same current state that the server would use if it started. Otherwise, what's the point? This shouldn't be at all hard to fix if that's not the way it works today. Because it may be on a different machine, for example. This is not a question of whether it is technically possible to make bundles mutable - the construction phase gets much easier if they are. It is whether they are usable by anything else after they have been mutated. I think we all agree that modifying attribute values and persisting the changes is a good idea. David has proposed saving this separately from the internal structure of the bundle and that seems like an idea worth exploring. I'd go further and suggest we separate bundle level properties from component level ones (at least for this kind of management) but that is something we really haven't discussed at all. I think this is a fine candidate for later refactoring.
Re: GBeans: Saving Changes
Aaron Mulder wrote: Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? The ability to build a configuration on one machine and have it run reliably on another. The ability for the packaging plugin to use artifacts from the Maven repo (using Maven's dependency system) rather than having to contact an online server. The ability to reliably run a worker server without a runtime deployment system. -- Jeremy
Re: GBeans: Saving Changes
All of those are broken today if you change the properties of the GBeans using the setAttribute calls, right? Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: The ability to build a configuration on one machine and have it run reliably on another. The ability for the packaging plugin to use artifacts from the Maven repo (using Maven's dependency system) rather than having to contact an online server. The ability to reliably run a worker server without a runtime deployment system.
Re: GBeans: Saving Changes
well... If the runtime deployer works off of the original configurations, ignoring any local modifications, it won't break anything, but it also will be pretty much useless (I think). If the runtime deployer works off of the locally modified configuration, then the runtime deployer should not be used to build configurations you intend to distribute to any other server. If you do, it breaks the immutability guarantees. BTW, I don't see how the runtime deployer can avoid using the locally modified configuration state -- you would have to find a way to load 2 copies of the same configuration at once. If the only changes allowed are attribute values, this is unlikely to have a really serious effect on the deployed configuration. Allowing more gbeans in is definitely going to welcome in all sorts of compatibility problems I continue to think adding gbeans at runtime will be a big mistake and that we don't see all the bad consequences yet. david jencks On Jul 26, 2005, at 4:48 PM, Aaron Mulder wrote: Okay, I think we're getting to the root of this. You believe I am proposing breaking a current feature. I believe I am proposing only adding new features without breaking anything. If we add the ability to add/remove GBeans to a configuration at runtime, then based on the current HEAD, which feature will that break? Thanks, Aaron On Tue, 26 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: FYI, I don't think this is a technical issue, I think this is a scope issue. You're talking about how to support build the bundle on a master node in a cluster and then automatically push it to worker nodes and how to support features that no other app server has. Yep, that was one of the design goals when we started on this, er, two years ago. And there are other servers that do this kind of thing, WebSphere-ND is one. I'm talking about how to provide a usable management environment for ONE server, which is something we most definitely need to be competitive. We have to get past reasonable 1-server support (plus of course add clustering support) before we need the features you're describing. None of these interfere with 1-server support. There's just no need to break N-server support that is already there whilst doing so, especially when people have already stated to talk about adding clustering support. I feel that we should proceed with a short-term option and plan to refactor when we are at a place where supporting the environment you're describing becomes feasible. It doesn't make sense to me to not proceed with any change until we can solve every problem we might ever have. No one is advocating not making any changes so please do not over dramatize the discussion. What doesn't make sense is breaking features we have now for a solution we have already identified has problems, planning on a refactoring say within 6 months to a mode that can't use the interim solution as there is no guarantee of consistency. Why not start the discussion on how to impove what we have e.g. by providing bundle level properties, by separating out management properties into an human-readable database rather than burying them in the config store, by separating manageable attributes from unmanageable ones used for wiring purposes, by adding bundle metadata? That said, back to the issue: On Tue, 26 Jul 2005, Jeremy Boynes wrote: The problem comes with which version of the state is used by things like the (runtime) deployer to build new configurations. If it uses the original then the new configuration may not run with the current one; if it uses the current then it may not run on a server using the original one. This is true today; if we don't implement add/remove, we still have the problem. For example, you could deploy an EJB that depends on a data source, then go change the password used by the data source to be invalid so it doesn't start or function, thereby breaking your EJB. This is true of every app server that I've ever used. I don't consider it to be a critical flaw of the product. But of course it would be nice to have a way around it down the road. That is a different problem - we didn't break your EJB, it failed because it could not connect to the database. The same problem would occur if the DBA changed the database password or took it down for maintenance. This is just a regular operational problem. This may never become apparent if the configurations are never moved between servers. However, being able to do that was half the point - e.g. build the bundle on a master node in a cluster and then automatically push it to worker nodes. It is also a requirement for offline or in-Maven packaging where the deployer will be using the original version and not the current modified one. Why won't the deployer use the current state in offline mode? If it touches it at all, it should use the same
Re: GBeans: Saving Changes
Aaron Mulder wrote: Let me try to propose some alternatives for us to consider. Assume you want to make a change to the server configuration, and for whatever reason, NOT bundle that with your application. This change involves adding or removing a GBean, which is naturally related to the content of the o/a/g/Server configuration. You want to make this change at runtime via the web console. First caveat - o/a/g/Server is too monolithic which is contributing factor to these discussions. The reasons why this is a problem and how to start to fix it have been discussed elsewhere. This impacts this discussion because of the clause which is naturally related to the content of the o/a/g/Server configuration. Let's assume o/a/g/Server is made more modular; the problem does not change, it just gets applies to the smaller bundles. Second caveat, change through the web console is one use case. It applies to small installations (desktop, single server) but is less applicable to larger installations, say with 10 servers. It also does not apply to headless servers which may not be running a web container at all. Do we all agree that this is a use case we wish to support? I do, but as you can tell from the caveats there are other use cases I also wish to see supported. snip/ skipping straight to suggestions of other alternatives :-) If you have any other alternatives to propose, please do so. I have two I've given some thought to although they're not fully thought out - but hey, we're brainstorming right? Option 5: We have two different bundle types, mutable and immutable. Mutable ones have a special ID, e.g. containing the word SNAPSHOT so they can be clearly identified; immutable ones have a specific version number e.g. o/a/g/Server/1.0-M5. Any structural modification of the bundle, e.g. adding a GBean, changing a reference pattern etc. makes the bundle mutable. We enhance the configuration manager so that it can handle bundle version ranges so that bundle-to-bundle dependencies are squishier than they are now. So, when the deployer builds the application it could say this application expects a Jetty bundle with version between 1.0.1 and 1.0.5 or a SNAPSHOT. Modifications through the web console that require strucutural change convert the config say o/a/g/Jetty-1.0.2 to o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for mutability will still run but ones that assume a release version won't. For desktop and small installations we do a default assembly using SNAPSHOT bundles; larger installations will probably build their own assemblies using released versions only. --- Option 6: We add a local bundle to the runtime that is used to hold stuff associated with this instance. This would be mutable and contain GBeans associated with this instance e.g. edge components like network listeners. With this model, a second HTTP connector would be added to the local bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not break for portable applications which only use components from named bundles. For this to work we will need to fix the classloader to provide the import/export mechanism add will need to be able to add imports to the local configuration at runtime. We need to be careful about adding multiple GBeans that require classes from conflicting imports. --- There may be the possibility of a combination of multiple options e.g. mixing local bundles with SNAPSHOTs or UUIDs. -- Jeremy
Re: GBeans: Saving Changes
Starting a new sub-thread... One of the examples we use all the time when talking about bundles is that of a web connector. However, this is bad example to take because it is too simple to highlight some of the issues. * it only contains one GBean * that bean has a couple of fairly simple properties * nothing references that GBean so it has little impact on other bundles I think the last issue there is systemic to this kind of component: it is an edge component that takes something from the outside world (i.e. an inbound socket connection) and hands it off to other services inside the server. So in Jetty, the HTTPConnector references the JettyContainer but not the other way around. The same can be said for other edge connectors such as the EJB Daemon, the ORB, the JMX Connector ... The first two issues also cloud things because they simplify the connector to a degenerate case. Things would be more interesting if we considered a HTTPS connector that split the functionality into three components: a socket listener, a thread pool and an SSL keystore. Then, when the user wanted to add an HTTPS port we would need to create three GBeans and wire them together properly. Bear in mind that depending on the runtime, the user may want the thread pool and SSL keystore to be bundled with the connector or may want to use ones from other bundles. Other things that may seem quite simple to the user may require several GBeans be constructed - this is what we do when we package an application, we create a new bundle with a bucket load of GBeans in it (e.g. servlet holders, ejb containers, admin objects, ...). Simplicity comes from not exposing all this detail to the user. -- Jeremy
Re: GBeans: Saving Changes
There is a mechanism to save out he current state of GBeans on a clean shutdown of the configuration (i.e., when you stop the configuration). If it is not running, then there is a bug. The code is in org.apache.geronimo.kernel.config.Configuration.doStop(); -dain On Jul 24, 2005, at 7:43 PM, Aaron Mulder wrote: So the console can write to persistent attributes of GBeans -- and I think they're taking effect (you can log out and log back in and see the changed value, at any rate). However, if you restart the server, the values reset to their initially generated values. I thought we had a mechanism in place to store the state of a GBean after a change at runtime -- which I assume would include storing new values for persistent attributes as well as storing the data for new GBeans added to a Configuration at runtime (for example, if you add a new network connector to the web container). I'm not sure whether this was never implemented, was implemented but is not working, is working but something needs to be called manually to execute the save, or is totally working and I'm misinterpreting what I'm seeing in the console. Any thoughts? Thanks, Aaron
Re: GBeans: Saving Changes
Aaron Mulder wrote: I thought we had a mechanism in place to store the state of a GBean after a change at runtime -- which I assume would include storing new values for persistent attributes as well as storing the data for new GBeans added to a Configuration at runtime (for example, if you add a new network connector to the web container). Configuration bundles are meant to be immutable so you shouldn't be adding things to them at runtime. Think of them as being similar to library jars or other maven artifacts - things would get very confusing if you started adding classes into them as part of a build. This allows the configuration to be identified by its ID in the same way the artifact id identifies a dependency to maven. Configuration bundles have attributes (currently modeled by exposing the GBeans they contain which is problematic) which pertain to the location in which they are being used. The *default* values for those attributes are contained inside the bundle; the instance value is set by the environment. There are some implementation issues in Geronimo today (short cuts taken for expediency) which obscure some of the subtleties of this model. Some of these relate to classloading (the issues on the packaging thread), others relate to GBean persistence. I'll give a couple of examples which I hope highlight a couple of the issues. The first anti-pattern is that configuration ids are not unique - we reuse them for different configurations. For example, although Tomcat and Jetty based servers are quite different we use the same unique id (org/apache/geronimo/Server) for both. We also reuse ids across versions so it is impossible to tell if an application deployed against org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is like only ever compiling against SNAPSHOT dependencies. Secondly, if configurations are immutable then you should not be able to add GBeans to them at runtime (that would be mutating them). So how do you add a network connector? The simplest model is to separate the web container from its connectors and build them as separate bundles (one for the container, one for each of the connectors); if you want to add a new connector you add a new instance of e.g. the HTTPS bundle. Finally, there is the issue of instance properties - things in the environment of where a configuration is being used that need to override the default properties that is has. For example, the default for the HTTP connector bundle might be to listen on port 8080 but on this server here it needs to be changed to be . Right now we do this by mutating the configuration installed in the store which is problematic. Instead it would be better to associate the state with the runtime and, after the bundle was loaded but before it was started, inject those local values into it. There's a fine line between when you want to override values on a per instance basis and when you want to define a new configuration for with those values as defaults. There's no right solution to that but I think the type of installation plays into it: * for a desktop development environment or single server installation then you are better just overriding properties as needed * for a clustered environment or large scale deployment then you are better defining reusable bundles that can be easily moved where/when they are required As Geronimo starts being considered for larger installations let's not forget what the original config system was designed to do. -- Jeremy
Re: GBeans: Saving Changes
For my part, I'm not convinced that it makes sense for configurations to be immutable. I think the export/import feature would be nice -- I finally got my web container configured 'just right', now let me export it and load it into my cluster of 30 boxes. I wouldn't even mind giving each configuration a unique hash or something such that we could eventually down the road add a feature where you export two related configurations, and one refers to that specific build of the other. Or even having an immutable flag on a configuration such that once you've marked one as immutable it refuses to change in the future. But to tell me that properties of a configuration shouldn't ever be changed, or that GBeans shouldn't be added or removed at runtime and we should create new child configurations instead... unless I'm misunderstanding you, that just doesn't work for me. I can't imagine someone customizing their web container and then after a few revs they try to load or unload or export it and discover that they now have configurations Server, Server HTTP v1..v5 Server HTTPS v1..v3 Server AJP v1 v2 Server Keystore v1..v4 Server accept thread pool v1 Server JSP Compiler v1..v3 Server request log v1..v5, and so on. Much better IMHO to let them alter the Server configuration to their heart's content, then let them export it or flag it as locked if they want to preserve a snapshot of that state. Thanks, Aaron On Mon, 25 Jul 2005, Jeremy Boynes wrote: Configuration bundles are meant to be immutable so you shouldn't be adding things to them at runtime. Think of them as being similar to library jars or other maven artifacts - things would get very confusing if you started adding classes into them as part of a build. This allows the configuration to be identified by its ID in the same way the artifact id identifies a dependency to maven. Configuration bundles have attributes (currently modeled by exposing the GBeans they contain which is problematic) which pertain to the location in which they are being used. The *default* values for those attributes are contained inside the bundle; the instance value is set by the environment. There are some implementation issues in Geronimo today (short cuts taken for expediency) which obscure some of the subtleties of this model. Some of these relate to classloading (the issues on the packaging thread), others relate to GBean persistence. I'll give a couple of examples which I hope highlight a couple of the issues. The first anti-pattern is that configuration ids are not unique - we reuse them for different configurations. For example, although Tomcat and Jetty based servers are quite different we use the same unique id (org/apache/geronimo/Server) for both. We also reuse ids across versions so it is impossible to tell if an application deployed against org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is like only ever compiling against SNAPSHOT dependencies. Secondly, if configurations are immutable then you should not be able to add GBeans to them at runtime (that would be mutating them). So how do you add a network connector? The simplest model is to separate the web container from its connectors and build them as separate bundles (one for the container, one for each of the connectors); if you want to add a new connector you add a new instance of e.g. the HTTPS bundle. Finally, there is the issue of instance properties - things in the environment of where a configuration is being used that need to override the default properties that is has. For example, the default for the HTTP connector bundle might be to listen on port 8080 but on this server here it needs to be changed to be . Right now we do this by mutating the configuration installed in the store which is problematic. Instead it would be better to associate the state with the runtime and, after the bundle was loaded but before it was started, inject those local values into it. There's a fine line between when you want to override values on a per instance basis and when you want to define a new configuration for with those values as defaults. There's no right solution to that but I think the type of installation plays into it: * for a desktop development environment or single server installation then you are better just overriding properties as needed * for a clustered environment or large scale deployment then you are better defining reusable bundles that can be easily moved where/when they are required As Geronimo starts being considered for larger installations let's not forget what the original config system was designed to do. -- Jeremy
Re: GBeans: Saving Changes
I have been thinking about this issue for months now and haven't come to any good solutions. I think it would be cool to have imutable configuration, but just think it is practical at this point. The console and the tomcat/jetty selection issues really show off where our current design falls short. Anyway, I haven't come up with anything to solve the overall problem, but I think allowing GBeans to be added and removed from a configuration is better then what we have today, so I'm +1 for it. If someone has a better idea we can add in short term 1.x timeframe, please speak up. Otherwise, I say make configuration mutable and we can make them immutable in 2.x when something better comes along. -dain On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote: For my part, I'm not convinced that it makes sense for configurations to be immutable. I think the export/import feature would be nice -- I finally got my web container configured 'just right', now let me export it and load it into my cluster of 30 boxes. I wouldn't even mind giving each configuration a unique hash or something such that we could eventually down the road add a feature where you export two related configurations, and one refers to that specific build of the other. Or even having an immutable flag on a configuration such that once you've marked one as immutable it refuses to change in the future. But to tell me that properties of a configuration shouldn't ever be changed, or that GBeans shouldn't be added or removed at runtime and we should create new child configurations instead... unless I'm misunderstanding you, that just doesn't work for me. I can't imagine someone customizing their web container and then after a few revs they try to load or unload or export it and discover that they now have configurations Server, Server HTTP v1..v5 Server HTTPS v1..v3 Server AJP v1 v2 Server Keystore v1..v4 Server accept thread pool v1 Server JSP Compiler v1..v3 Server request log v1..v5, and so on. Much better IMHO to let them alter the Server configuration to their heart's content, then let them export it or flag it as locked if they want to preserve a snapshot of that state. Thanks, Aaron On Mon, 25 Jul 2005, Jeremy Boynes wrote: Configuration bundles are meant to be immutable so you shouldn't be adding things to them at runtime. Think of them as being similar to library jars or other maven artifacts - things would get very confusing if you started adding classes into them as part of a build. This allows the configuration to be identified by its ID in the same way the artifact id identifies a dependency to maven. Configuration bundles have attributes (currently modeled by exposing the GBeans they contain which is problematic) which pertain to the location in which they are being used. The *default* values for those attributes are contained inside the bundle; the instance value is set by the environment. There are some implementation issues in Geronimo today (short cuts taken for expediency) which obscure some of the subtleties of this model. Some of these relate to classloading (the issues on the packaging thread), others relate to GBean persistence. I'll give a couple of examples which I hope highlight a couple of the issues. The first anti-pattern is that configuration ids are not unique - we reuse them for different configurations. For example, although Tomcat and Jetty based servers are quite different we use the same unique id (org/apache/geronimo/Server) for both. We also reuse ids across versions so it is impossible to tell if an application deployed against org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is like only ever compiling against SNAPSHOT dependencies. Secondly, if configurations are immutable then you should not be able to add GBeans to them at runtime (that would be mutating them). So how do you add a network connector? The simplest model is to separate the web container from its connectors and build them as separate bundles (one for the container, one for each of the connectors); if you want to add a new connector you add a new instance of e.g. the HTTPS bundle. Finally, there is the issue of instance properties - things in the environment of where a configuration is being used that need to override the default properties that is has. For example, the default for the HTTP connector bundle might be to listen on port 8080 but on this server here it needs to be changed to be . Right now we do this by mutating the configuration installed in the store which is problematic. Instead it would be better to associate the state with the runtime and, after the bundle was loaded but before it was started, inject those local values into it. There's a fine line between when you want to override values on a per instance basis and when you want to define a new configuration for with those values as defaults.
Re: GBeans: Saving Changes
As far as the Tomcat/Jetty thing goes, that will be interesting to explore as we think over how we should deal with interfaces in some future release. I mean, I think our dependencies should ideally be expressed as I require a servlet 2.4-compatible web container not I require the configuration named o/a/g/Server. Though to Jeremy's point, I can also see that if you get everything working just so with Jetty version X, you may not be all that eager to have your production team deploy it onto Tomcat instead just because that's a compatible interface. I guess we need to put some more thought into exactly what use cases we're trying to support. Aaron On Mon, 25 Jul 2005, Dain Sundstrom wrote: I have been thinking about this issue for months now and haven't come to any good solutions. I think it would be cool to have imutable configuration, but just think it is practical at this point. The console and the tomcat/jetty selection issues really show off where our current design falls short. Anyway, I haven't come up with anything to solve the overall problem, but I think allowing GBeans to be added and removed from a configuration is better then what we have today, so I'm +1 for it. If someone has a better idea we can add in short term 1.x timeframe, please speak up. Otherwise, I say make configuration mutable and we can make them immutable in 2.x when something better comes along. -dain On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote: For my part, I'm not convinced that it makes sense for configurations to be immutable. I think the export/import feature would be nice -- I finally got my web container configured 'just right', now let me export it and load it into my cluster of 30 boxes. I wouldn't even mind giving each configuration a unique hash or something such that we could eventually down the road add a feature where you export two related configurations, and one refers to that specific build of the other. Or even having an immutable flag on a configuration such that once you've marked one as immutable it refuses to change in the future. But to tell me that properties of a configuration shouldn't ever be changed, or that GBeans shouldn't be added or removed at runtime and we should create new child configurations instead... unless I'm misunderstanding you, that just doesn't work for me. I can't imagine someone customizing their web container and then after a few revs they try to load or unload or export it and discover that they now have configurations Server, Server HTTP v1..v5 Server HTTPS v1..v3 Server AJP v1 v2 Server Keystore v1..v4 Server accept thread pool v1 Server JSP Compiler v1..v3 Server request log v1..v5, and so on. Much better IMHO to let them alter the Server configuration to their heart's content, then let them export it or flag it as locked if they want to preserve a snapshot of that state. Thanks, Aaron On Mon, 25 Jul 2005, Jeremy Boynes wrote: Configuration bundles are meant to be immutable so you shouldn't be adding things to them at runtime. Think of them as being similar to library jars or other maven artifacts - things would get very confusing if you started adding classes into them as part of a build. This allows the configuration to be identified by its ID in the same way the artifact id identifies a dependency to maven. Configuration bundles have attributes (currently modeled by exposing the GBeans they contain which is problematic) which pertain to the location in which they are being used. The *default* values for those attributes are contained inside the bundle; the instance value is set by the environment. There are some implementation issues in Geronimo today (short cuts taken for expediency) which obscure some of the subtleties of this model. Some of these relate to classloading (the issues on the packaging thread), others relate to GBean persistence. I'll give a couple of examples which I hope highlight a couple of the issues. The first anti-pattern is that configuration ids are not unique - we reuse them for different configurations. For example, although Tomcat and Jetty based servers are quite different we use the same unique id (org/apache/geronimo/Server) for both. We also reuse ids across versions so it is impossible to tell if an application deployed against org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is like only ever compiling against SNAPSHOT dependencies. Secondly, if configurations are immutable then you should not be able to add GBeans to them at runtime (that would be mutating them). So how do you add a network connector? The simplest model is to separate the web container from its connectors and build them as separate bundles (one for the container, one for
Re: GBeans: Saving Changes
I'd ask you to set aside traditional thinking and try this out for a bit. When you write code, you edit a couple of source files, compile it, fix the typos, build a jar, test it, decide its good enough and commit the change. After doing this a few times you decide its good enough and do a release, taking the jar file you built and saving for posterity. You then do it all over again. If you're doing this with Maven, it spells out the difference between the jar you are working with (a SNAPSHOT) and the jar you release (something with a version number). Sound familiar? In a large production environment you do the same kind of thing with system configurations. You set up a system the way you want, check that it works, beat the snot out of it (aka stress testing or benchmarking), see how/when it falls over, tweak the config and repeat until it you're happy, then document it, have someone else try the change in your staging environment, check it still works, then beg the change control board to let you move it to production at 3AM on a Sunday morning. You then cross your fingers and hope it really works. A bit different from changing things on a desktop machine or the box that runs the family website, but not unrealistic and the problem the architecture was trying to simplify. [[ to avoid a disgression, is Geronimo ready for this? Who knows; in the end the people doing such things factor in the risks associated with any software no matter how mature and they will make up their own minds ]] The idea behind the configuration bundles is that they are pre-wired sets of closely coupled components that co-ordinate to perform a specific task. A single bundle is *not* meant to represent the entire system assembly - the current o/a/g/Server is an abberation caused by problems in the classloader model (described elsewhere) not example of best practice. The purpose of a bundle is to allow a knowledgable person to, for example, pre-wire a web container in a way that allows other people to use it just by defining a few characteristics. So, for example, someone can go to a repository and find, for example, a pre-wired version of a Jetty bundle pre-configured for 100 concurrent users at 95% static content with a typical dynamic reponse time of 500ms when running on an Acme-4000 Linux machine. So why does this need to be immutable? Because if you are pulling these things from a catalog then you need to know that you're going to get what you expect and not some version that someone happened to tweak but just forgot to change the name. It would be like having several jar files out there called log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW one reason bundles are JAR files is because it's dead easy to sign them so that you can tell if they have been tweaked. Now, just as in the code development example I gave at the top, these kind of pre-packaged bundles are also going to go through a development process. One reason we didn't version stamp the configIds in the current assembly is that until now all our configurations have really been in development and it didn't make sense to be dealing with new versions all the time. It probably would have been clearer to id them as e.g. o/a/g/Server/1.0-SNAPSHOT but I guess that's water under the bridge now. So, in an ideal world, your user below would just pick a suitable pre-built bundle out of some repo and be happy with what it does. If it doesn't quite do what they want or nothing suitable can be found, they start by building and tweaking my/web/Container/1.0-SNAPSHOT, iterate it a few times and then finalize on my/web/Container/1.0. The problem is identical to a developer not filling up their Maven repo with trivially different versions of a jar they are working on (which is why Maven has SNAPSHOTs in the first place). To pick a bad analogy, we're trying to do with server configuration what Maven did for builds. No, I don't mean trying to make it slow and take forever to start. We're trying to simplify the administration process by allowing a admin to choose from a re-usable set of pre-optimized bundles rather than having to do it all by hand, in the same way Maven uses plugins to replace manually created ant scripts. It's different. It's unusual. It takes some getting used to. But it might just work. -- Jeremy Aaron Mulder wrote: For my part, I'm not convinced that it makes sense for configurations to be immutable. I think the export/import feature would be nice -- I finally got my web container configured 'just right', now let me export it and load it into my cluster of 30 boxes. I wouldn't even mind giving each configuration a unique hash or something such that we could eventually down the road add a feature where you export two related configurations, and one refers to that specific build of the other. Or even having an immutable flag on a configuration such that once
