4/27/2017 8:53:57 PM
example is the following:
/Users/afaris/work/public/li-afaris_azkaban/azkaban-web-server/src/main/java/azkaban/webapp/WebMetrics.java:37: warning: [ImmutableEnumChecker] enums should only have immutable fields, the declaration of type 'com.codahale.metrics.Meter' is not annotated @Immutable private final Meter webGetCall; ^ (see http://errorprone.info/bugpattern/ImmutableEnumChecker)
|
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.
|
