new charm submission for ksplice service

Bug #1414204 reported by Anthony Fappiano
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juju Charms Collection
In Progress
Undecided
Unassigned

Bug Description

This bug is to create a new recommended charm for the ksplice service.

Revision history for this message
Cory Johns (johnsca) wrote :

Anthony,

Thank you for this charm submission. This looks like it will be very useful in helping keep units patched and up to date. We had a few comments, however, only one of which I really consider blocking.

First, we very much appreciate that you included a test in this charm. However, the fact that it requires manual input means that it will cause issues with our automated test runner, bundletester. We checked to confirm that the charm deploys successfully when given a bogus accesskey, and, while obviously the ksplice / uptrack service will not actually work, it should be enough for the 01_deploytest.py to pass. Barring getting a "test key" from Oracle that would allow us to actually test the functionality of the deployed KSplice, I think confirming the deployment with a bogus key is going to be the best test we can have.

Second, while the charm is generally very cleanly implemented, and you are including charmhelpers and making some use of it, you are also reimplementing several functions that are available in charmhelpers. I'd like to recommend that you consider refactoring the charm to use the following alternatives:

  * utils.config_get -> core.hookenv.config
  * utils.juju_log -> core.hookenv.log
  * utils.config_repo -> fetch.add_source
  * utils.render_template -> core.templating.render
  * resources.directory -> core.host.mkdir

I also noted that `charm proof` gives informational messages due to the start and stop hooks being missing. You could put no-op placeholders in for these hooks to clean up these messages, but this is definitely non-blocking.

Finally, you have the charm going into an (error) state if the accesskey config option is not set, thus requiring the user to `juju resolved --retry` the charm after setting the option. It might be nicer to simply log the CRITICAL message and defer the setting of the package config, so that it is just a one-step process to resolve, but I can understand the argument that there is not yet a better way to communicate to the user that manual intervention is required.

Thanks again for this charm, and I look forward to getting it approved into the store.

Revision history for this message
Anthony Fappiano (anthony-fappiano) wrote :

Hi Corey-
  Thanks for the feedback, I'm working on these suggestions now and should have something to be re-reviewed shortly.

Thanks,

-A

Revision history for this message
Matt Bruzek (mbruzek) wrote :

Hello Anthony,

I haven't seen any movmeent on this bug so I am going to put it in "In Progress", please move it to "Fix Committed" when you want another review.

Thanks!
  - Matt

Changed in charms:
status: New → In Progress
Revision history for this message
Review Queue (review-queue) wrote : HP Test Results: new charm submission for ksplice service

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-hp/1087/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.