Bug 15088 - Notice when koha has been installed with --request-db instead of --create-db
Summary: Notice when koha has been installed with --request-db instead of --create-db
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Liz Rea
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-30 02:30 UTC by Liz Rea
Modified: 2016-07-06 14:21 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15088 - notice when koha has been installed with --request-db instead of --create-db (4.96 KB, patch)
2015-11-03 21:58 UTC, Liz Rea
Details | Diff | Splinter Review
Bug 15088 - Follow for koha-create (1.24 KB, patch)
2016-02-17 14:15 UTC, Mark Tompsett
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 15088 - notice when koha has been installed with --request-db instead of --create-db (5.02 KB, patch)
2016-02-17 14:59 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 15088 - Follow for koha-create (1.24 KB, patch)
2016-02-17 14:59 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 15088 - Follow for koha-create (1.29 KB, patch)
2016-06-03 13:31 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2015-10-30 02:30:05 UTC
If you try to remove a Koha instance that is using a remote database, it will fail and the sysadmin will feel sad.

We already provide a mechanism by which we don't touch the mysql bits (--keep-mysql), it might be nice to explain in the help that using this will allow a sysadmin to remove the front-end of Koha and remove the remote database independently, at a later (or previous) time.

I don't think we need a different option, maybe the existing one needs a different name... I'm not really sure.
Comment 1 Liz Rea 2015-10-30 02:32:36 UTC
the only option name that is coming to my mind on this sunny friday afternoon is "--no-touchy-the-database-bits" I don't think that would really be good. :)
Comment 2 Liz Rea 2015-11-03 21:58:20 UTC Comment hidden (obsolete)
Comment 3 Liz Rea 2015-11-04 03:35:09 UTC
(I had a bit of a change of heart on how to handle this, after consulting with the most excellent Robin.)
Comment 4 Mark Tompsett 2016-02-16 21:41:24 UTC
"Koha instance is empty, no staff user created."
-- Oops. In a fresh install without a pre-existing DB, this doesn't work.
Comment 5 Liz Rea 2016-02-16 21:44:07 UTC
I don't understand, that behaviour predates this patch.

Liz
Comment 6 Mark Tompsett 2016-02-17 13:12:16 UTC
(In reply to Liz Rea from comment #5)
> I don't understand, that behaviour predates this patch.
> 
> Liz

That's not the issue. Read the code. I called a fresh install with create DB and the createoptions file was empty, because it generated the else case. That's the else case message. That's why I put it to Failed QA, because it doesn't notice when it was called with --create-db in the case of a fresh install.
Comment 7 Mark Tompsett 2016-02-17 14:15:05 UTC Comment hidden (obsolete)
Comment 8 Mark Tompsett 2016-02-17 14:59:29 UTC
Created attachment 48186 [details] [review]
[SIGNED-OFF] Bug 15088 - notice when koha has been installed with --request-db instead of --create-db

Patch does 2 major things -

* creates an options file during koha-create that lets us know what database option was used when the instance was created
/etc/koha/sites/$name/createoptions
* when an instance is removed, we assume we can do things to the database, per usual. If we have a createoptions, we'll read it and find out if our instance was created with create-db or request-db.
If it was requested, we don't do anything with the database because we assume we don't have rights to, and print a message.
If it was created, we do the same thing we've always done - remove the database and users (unless we've specified --keep-mysql)

To test:

create a throwaway instance with --create-db
remove that instance, all should happen as normal.
your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=0 in it.

create another throwaway instance with --request-db
remove that instance, you should see a message alerting you to the fact that you may still have database work to do after Koha is removed.
your instance should have an /etc/koha/sites/$name/createoptions file with REQUEST_DB=1 in it.

NOTE: Only works in conjuction with my patch.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Comment 9 Mark Tompsett 2016-02-17 14:59:39 UTC Comment hidden (obsolete)
Comment 10 Mark Tompsett 2016-02-17 15:00:56 UTC
If you could test and sign off, Liz, I would be glad to have this set to signed off.
Comment 11 Chris Cormack 2016-06-03 13:31:48 UTC
Created attachment 52004 [details] [review]
Bug 15088 - Follow for koha-create

Logic in the koha-create was requiring a DEFAULTSQL to trigger.
This patch moves it, such that --create-db will be registered
all the time.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 12 Jonathan Druart 2016-06-06 14:15:02 UTC
Just to make sure: We are creating a new options and a new file, just to display an alert?
Why not try to drop it and display the alert if the DB has not been deleted?
Comment 13 Liz Rea 2016-07-05 02:39:26 UTC
Hi,

Yes, that is what we're doing. When you put it that way, it seems crazy.

However, crazy as it sounds, my thinking was that there might eventually be other things that we wanted to keep track of in a centralised location.
 
I see it as the first instance of having a method of making a Koha self-documenting. A way to make sure we can know how a koha was originally installed, a way to ease troubleshooting for admins, a way to provide explicit error messages for specific types of installations. As Koha installations pass from admin to admin, knowledge is lost. When the knowledge is lost, libraries leave Koha. 

This desire of mine may not be enough to encourage acceptance of this patch. That's fine. I just wanted to make sure you knew where my head and heart were at when I submitted this in this way.

Liz
Comment 14 Jonathan Druart 2016-07-06 14:21:41 UTC
Ccing Tomas to get his opinion.