On Tue, Jul 19, 2016 at 4:16 PM, Roman Shaposhnik <[email protected]> wrote: > On Tue, Jul 19, 2016 at 2:58 PM, Cory Johns <[email protected]> wrote: >> In the Juju charms we are adding to Apache Bigtop, one of the scenarios we >> want to handle is upgrading from one Bigtop release to another. I tried to >> find documentation on how to upgrade a Bigtop release, but my google-fu >> failed me. > > That's because I don't think it exists ;-) > > The biggest hurdle is the fact that you can really only upgrade at > stack-level, > not individual component's level (the dependencies seep into the > implementation).
Is it correct to stay one can install bigtop-1.0.0 and then upgrade to 1.1.0. If so, how is service specific upgrades between Bigtop versions handled? I think that is the root of the question, and the answer may very well be it is service specific. We just wanted to check if there were any specific "hooks" we could call to invoke an in-place upgrade, or migrate service/jobs/data to a newer version of the application. > >> What is the recommended way to upgrade a deployment of Apache Bigtop to a >> new Bigtop release? Does Bigtop support in-place upgrades, or is it >> designed to do a side-by-side deployment of the new version and transition >> to that? > > Actually, that's a great question for you, Canonical guys. Isn't part > of the reason > you came up with the new packaging format (snap) the fact that traditional > DEBs > make side-by-side installs of different versions of the same stack > next to impossible? Snaps are intended to help encapsulate application dependencies and provide a transactional method for updates. Both snaps and debs provide a method for the user to install a specific version of the app. Where snaps excel is the transactional layer of dependencies a given version of the application requires. Snaps also provide the ability to just change the bits in the application needed for the upgrade. In debs we can accomplish the same but it may require extra work on an apt cache or modifying the package to require specific version. These are just frameworks to model how an application should be upgraded. Debs or snaps can certainly be upgraded side-by-side or in-place, but I think that is very dependent on how the application is designed to be upgraded. In this context we would certainly like all upstreams to use snaps, but today that isn't the case. Thus, we wanted to query folks here on the best practices to upgrade applications provided by Bigtop. For example, is there Bigtop best practice to upgrade Sqoop, Spark, or Hadoop? Or should we query the Apache specific project for best practices on upgrading? We wanted to ensure if there was a Bigtop best practice for upgrades we were using that, and if not we wanted to open a discussion on the best way to tackle that issue. Thoughts? -thanks, Antonio > > So let me flip that question on you: what's Ubuntu's guidance on that? With > RPM > you can at least try to do relocatable RPMs and install them under the stack > trees to facilitate rolling upgrades, with DEB, I don't think it is possible. > > Thanks, > Roman.
