7:08 a.m.
Team,
I'm moving Accounts to Cassandra, so that Hawkular won't need a RDMBS
just because of it.
I tried to keep backwards compatibility, but there's one part that could
break your code: the models are now using UUIDs for the IDs. Previously,
the IDs were strings, which were UUIDs as string by default, but your
component had the freedom to specify an own ID.
As far as I know, only Inventory specifies its own ID for the Resource
class. It seems that Jirka is OK with changing it to UUID, but if you
have any problems with that, let me know and I'll remove this requirement.
Note that if all you do is consume the IDs generated by Accounts, you
should *not* be affected, as all old methods are converting the UUIDs
that you send as String back to UUID.
Apart from that, it should be fully backwards compatible, but in any
case, I'll be releasing accounts 1.0.17.Final and branching 1.0.x.
Cassandra changes will be applied to 1.1.0.Final. All changes from
1.1.0.Final and on will be backported to 1.0.x *up to the next MS*. If
everything goes right for the next MS, I'll stop maintaining 1.0.x.
- Juca.
7:57 a.m.
On 10/27/2015 12:08 PM, Juraci Paixão Kröhling wrote:
I'm moving Accounts to Cassandra, so that Hawkular won't need
a RDMBS
just because of it.
I guess this point is a bit misleading: while our Hawkular components
wouldn't need a RDMBS, Keycloak still needs might require one.
- Juca.
8:14 a.m.
Can you clarify what ID you are talking about? This isn't the resource IDs is it? The
IDs that feeds create and send to inventory and metrics? AFAIK, the hawkular design for
these IDs was that feeds were free to create their own IDs with their own formats/syntax
(so long as they are Strings).
But I have a feeling the "ID" you are talking about is different - but I just
wanted to clarify to make sure.
----- Original Message -----
Team,
I'm moving Accounts to Cassandra, so that Hawkular won't need a RDMBS
just because of it.
I tried to keep backwards compatibility, but there's one part that could
break your code: the models are now using UUIDs for the IDs. Previously,
the IDs were strings, which were UUIDs as string by default, but your
component had the freedom to specify an own ID.
As far as I know, only Inventory specifies its own ID for the Resource
class. It seems that Jirka is OK with changing it to UUID, but if you
have any problems with that, let me know and I'll remove this requirement.
Note that if all you do is consume the IDs generated by Accounts, you
should *not* be affected, as all old methods are converting the UUIDs
that you send as String back to UUID.
Apart from that, it should be fully backwards compatible, but in any
case, I'll be releasing accounts 1.0.17.Final and branching 1.0.x.
Cassandra changes will be applied to 1.1.0.Final. All changes from
1.1.0.Final and on will be backported to 1.0.x *up to the next MS*. If
everything goes right for the next MS, I'll stop maintaining 1.0.x.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:29 a.m.
On 10/27/2015 01:14 PM, John Mazzitelli wrote:
Can you clarify what ID you are talking about? This isn't the
resource IDs is it? The IDs that feeds create and send to inventory and metrics? AFAIK,
the hawkular design for these IDs was that feeds were free to create their own IDs with
their own formats/syntax (so long as they are Strings).
Inventory folks can correct me if I'm wrong, but as far as I understand,
Inventory uses the path as the ID on their side. That's their "Resource".
When dealing with Accounts, they reuse this ID if the path's length is
smaller than X. If it's bigger than X, then they resort to UUID when
talking to accounts.
So, I assume that consumers of Inventory won't be affected by this
change, as inventory is already translating between path-based IDs and
UUIDs.
- Juca.
7:29 a.m.
Team,
On 10/27/2015 12:08 PM, Juraci Paixão Kröhling wrote:
Cassandra changes will be applied to 1.1.0.Final. All changes from
1.1.0.Final and on will be backported to 1.0.x *up to the next MS*. If
everything goes right for the next MS, I'll stop maintaining 1.0.x.
I just submitted PRs for the following components:
Alerts
https://github.com/hawkular/hawkular-alerts/pull/117
BTM
https://github.com/hawkular/hawkular-btm/pull/221
Command Gateway
https://github.com/hawkular/hawkular-command-gateway/pull/29
Inventory
https://github.com/hawkular/hawkular-inventory/pull/188
I'd please ask you to review and merge them today or, at most, tomorrow,
as I'll be out from Friday for about a week. After that, we'll be close
to the next MS date, so, I'd rather have this feature fully merged soon,
so that we have enough time for testing it.
Once those are merged, a PR for Agent will be sent, with updated
versions of Command Gateway and Accounts.
After that, a PR will be sent to Hawkular with the src-deps tag for the
merged PRs. Please, let me know if your component has a "blocker" that
would cause failures on Hawkular if its current master + PR is used there.
- Juca.
3096
days inactive
3103
days old
4 comments
2 participants
participants (2)
-
John Mazzitelli -
Juraci Paixão Kröhling