4/27/2017 8:38:01 PM
in azkaban-common package
|
4/27/2017 8:32:16 PM
warning: [ImmutableEnumChecker] enums should be immutable, and cannot have non-final fields private int numVal; ^ (see http://errorprone.info/bugpattern/ImmutableEnumChecker) Did you mean 'private final int numVal;'?
|
|
|
4/27/2017 5:50:55 PM
subproject introduction
This patch includes akzbana-db subproject, which defines new SQL
interfaces to interact with JDBC libraries. The goal of this design is
to have database retires more easily and add more monitoring metrics in
future.
|
4/27/2017 5:21:48 PM
Storage. (#1024)
The `project_versions` table currently stores all metadata corresponding to every upload of a project zip. The newly introduced storage layer in azkaban requires the persistence of an additional field in the `project_versions` table `uri`.
```
CREATE TABLE project_versions (
...
uri VARCHAR(512) DEFAULT NULL,
...
);
```
The changes integrate `uri` in the query APIs in `ProjectLoader` and modify the interfaces in a *backward incompatible* manner. The solo server SQL scripts have been updated accordingly and have been tested to work.
Existing installations of Azkaban *will* require a simple DB migration: `uri` field addition to `project_versions`.
This completes the implementation for `LOCAL` and `DATABASE` storage types. By default, the storage will continue to be `DATABASE`. (DB migration will still be required)
To change to `LOCAL` storage. Add this to `conf/azkaban.properties`
```
azkaban.storage.type=LOCAL
```
This has been tested to work on solo server and also tested on dev clusters.
|
4/26/2017 7:29:21 PM
some never-used code, remove it. Also, refactor a little a bit in
these classes.
|
4/26/2017 7:15:31 PM
Remove StorageConfig and move everything to AzkabanCommonModuleConfig. This creates a config container which can be used for all classes in azkaban-common. If the config grows too large, we can always refactor later. Besides currently there is no config class for the modules.
Added HDFS storage implementation stub. Following changes will implement the APIs.
|
4/26/2017 2:16:14 PM
delegates all get calls via the `StorageManager`. By `get` I mean the process of fetching a project file (blob) from storage. By default, this storage is the database. There are some hacks in the code which can be fixed later as we go.
There are some refactors in the executor codebase. This was done to easily fetch the `StorageManager` class via Guice.
The changes have been verified on solo server locally and also on executors separately.
Others - Changed catch block as per previous review comment - Updated todos with more detail
|
4/26/2017 1:10:52 PM
to have returned also the cron schedule at /schedule?ajax=loadFlow endpoint.
|
4/25/2017 8:08:14 PM
(#1015)
Root level Guice injection has been added to web server, executor and
solo server. This change ensures that the main server classes are
injected as opposed to manually constructed. This can help us refactor
the code further and introduce the major classes as Guice dependencies.
The code has been tested on solo, web and executor instances both
locally and on the grid. Unit testing these modules are currently not
easy due to the code structure. However, Guicification will help us a
lot in moving towards that direction.
|
