lp:~martinarrieta/mysql-fabric/BUG-72094

Created by Martin Arrieta on 2014-05-14 and last modified on 2014-05-14
Get this branch:
bzr branch lp:~martinarrieta/mysql-fabric/BUG-72094
Only Martin Arrieta can upload to this branch. If you are Martin Arrieta please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Martin Arrieta
Project:
MySQL Fabric
Status:
Development

Recent revisions

225. By Martin Arrieta on 2014-05-14

Added support to use the server_address or the uuid in the fetch command

224. By Martin Arrieta on 2014-05-14

Added support to use the server_address or the uuid in the fetch command

223. By Alfranio Correia <email address hidden> on 2014-03-25

BUG#72117: BUG#18454582: SCHEDULER DOES NOT NOTIFY ALL PROCEDURES THAT ARE FREE TO GO AFTER A RELEASE

The scheduler is not notifying all procedures that were blocked by a procedure
that has had its locks released. The current algorithm checks all the queues
for the objects locked by the procedure which has finished but does not check
that some procedures are at head of the queue already for other objects.

For example,

   ['object_1'] = [procedure_1, procedure_2]
   ['object_2'] = [procedure_2]

If "procedure_1" finishes the execution, the scheduler does notify that
"procedure_2" can continue its execution because only the queue for
"object_1" has changed after releasing the locks for "procedure_1".

222. By Alfranio Correia <email address hidden> on 2014-03-18

BUG#72016 BUG#18403885 AUTOMATIC FAILOVER IS NOT HAPPENING WHEN GLOBAL GROUP MASTER IS FAILED

The shard sub-system creates a replication channel between a global group and
a shard group. Specifically, the master in the global group replicates its
changes to the master in the shard group.

Although there is this relationship, the high availability routines should
work independently in the sense that any high availability operation in the
groups should work regardless the existence of a valid master or not in the
related group(s). This was not happening though and an exception was raised
thus aborting the high availability operation(s).

We have fixed this behavior in the context of this patch. Now if there is
no valid master in a related group, an error message is printed out and
the operation continues.

221. By Johannes Schl├╝ter on 2014-03-10

Merge 1.4

220. By Mats Kindahl on 2014-03-07

Merging with trunk

219. By Mats Kindahl on 2014-03-07

Releasing version 1.4.2

218. By Geert JM Vanderkelen on 2014-03-07

Post-push fix for WL#7455.

* 'username' in section [protocol.xmlrpc] is now 'user'
* Added new command `user list`
* Added --user option for all commands
* `manage setup` will use credentials found in configuration file
  for initial setup, preventing asking password.
* Command line options --protocol and --roles reworked
* Configuration file contains all new options

217. By Alfranio Correia <email address hidden> on 2014-03-04

Post-push fix for WL#7455.

Added disable_authentication option to the test cases so that we can run
them without requiring credentials.

216. By Geert JM Vanderkelen on 2014-03-04

WL#7455: Credentials for Fabric

Before, MySQL Fabric did not have any authentication
mechanism. We have added credentials with a role-based
system. Users executing commands will need to provide
a username and password together with a realm.

Setup
-----
The setup command will create new tables managing the
users, roles and permissions. It will also prompt for
a password to be set for the default user 'admin'. The
default realm for XMLRPC will be 'MySQL Fabric' when
it was not specified in the configuration file.

User Management
---------------
Most commands executed using mysqlfabric script will
prompt for a username and password. This can be set in
the configuration file under section [protocol.xmlrpc]
to prevent continuously asking credentials.
Commands like start and setup do not require
authentication.

Users can be managed through the commands found in the
'user' group, see `mysqlfabric help user`:
     user add <username> [<option> ...]
     user delete <username> [<option> ...]
     user password <username> [<option> ...]
     user roles <username> [<option> ...]

Any command that needs it, will prompt at least for a
password. See `mysqlfabric help user <command>`.

It is also possible to show the currently available
roles and permissions, but no other management can
be currently done. See `mysqlfabric help role`.

Note that user management is local and is currently
not done through protocols such as XMLRPC.

Authentication
--------------
Authentication can be disabled through the configuration
file by setting 'disable_authentication' to 'yes' in
the [protocol.xmlrpc] section. This can be useful for
testing, but by default authentication is enabled.

Client authenticate through XMLRPC using HTTP/1.1
Digest Authentication. We implemented RFC 2617 with
hashing function MD5. Other mechanisms can be added
later but MD5 is probably easiest to implement by
client libraries.

Connectors will best connect with a user which has
restricted permissions. A role named 'connector' has
been created for this and gives, by default, access
to the 'dump' and 'threat' commands.

SSL Support
-----------
The configuration section [protocol.xmlrpc] has 3 new
options named ssl_ca, ssl_key and ssl_cert. They are
used to enable SSL. When they are commented out or
removed, SSL is not set up. SSLv3 is currently used.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:mysql-fabric
This branch contains Public information 
Everyone can see this information.

Subscribers