Re: [jclouds] Always return ETag in filesystem object store get response (#850)
> LocalBlobStore calls getBlob on the storage strategy during listContainer, > this change will make it unbearably slow for the cases when the md5 needs to > be generated at run time. That's unfortunate, though it looks like this patch simply closed a corner case on OS X, where the user extended attribute view is non-null but still extended attributes are not supported; on a system where `getUserDefinedFileAttributeView` was returning null anyway, we'd already have recomputed the hash. I'm honestly fine with behavior going either way, but would prefer uniformity. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/850#issuecomment-133583527
Re: [jclouds] Always return ETag in filesystem object store get response (#850)
`LocalBlobStore` calls getBlob on the storage strategy during listContainer, this change will make it unbearably slow for the cases when the md5 needs to be generated at run time. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/850#issuecomment-133578347
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
Thanks @cdancy ! That sounds perfect.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37645426
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
@zack-shoylev I think you made the point previously, maybe here or on IRC, that
I agree with in that builders, at least so far as AutoValue classes are
concerned, should be used when those classes are client facing. In this case
the CreateMember class would be just that and so I think it makes sense to
Builderize (?!?) it. Other classes which are not client facing, and are simply
handed back from a function call, need not have this functionality. Maybe this
is obvious but I thought it a point worth making. I'm actually writing up the
builder class now so if we are in agreement I can send in another squashed
commit with the builder functionality added on top. Going forward I will follow
the same model with this provider, that being: client facing value classes will
get builders if only to keep things consistent.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37641771
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +import com.google.auto.value.AutoValue;
> +import com.google.common.collect.ImmutableList;
> +
> +@AutoValue
> +public abstract class Member {
> +
> + public abstract String id();
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + Member() {
A-ha! Thanks @nacx !
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37639680
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
@nacx I just think it's convenient and consistent to provide the Builder,
especially because auto-value takes care of most of it.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37639569
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
I'd say don't use builders by default. We are talking about value objects that
should be simple by nature. Using builders everywhere by default sounds like
unnecessary over-engineering, but that's only my opinion :)
In this case, it has only three fields and perhaps makes more sense to provide
several factory methods (if needed).
This said, I think consistency is important, so if the general case in this API
is that value objects *users will build* are complex or justify the use of a
builder, then use them.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37639213
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +import com.google.auto.value.AutoValue;
> +import com.google.common.collect.ImmutableList;
> +
> +@AutoValue
> +public abstract class Member {
> +
> + public abstract String id();
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + Member() {
It is a best practice. See:
https://github.com/google/auto/blob/master/value/README.md#best-practices
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37638183
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +import com.google.auto.value.AutoValue;
> +import com.google.common.collect.ImmutableList;
> +
> +@AutoValue
> +public abstract class Member {
> +
> + public abstract String id();
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + Member() {
I see. =\ I am not aware of any issues if these are removed. Unless there is a
code doc explaining why these are needed, I think remove.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37632572
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +import com.google.auto.value.AutoValue;
> +import com.google.common.collect.ImmutableList;
> +
> +@AutoValue
> +public abstract class Member {
> +
> + public abstract String id();
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + Member() {
@zack-shoylev just following conventions I've seen elsewhere within
jclouds-labs by providing an empty constructor for AutoValue classes. If the
standard going forward is to remove these, as they are not really needed
anyway, then I'm more than happy to remove it ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37632279
Re: [jclouds] JCLOUDS-826: Remove filesystem (#846)
Closed #846. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/846#event-388780327
Re: [jclouds] JCLOUDS-826: Remove filesystem (#846)
Thank you all for the feedback! With the (big) exception of managing existing files, I think a drop-in replacement should be more-or-less possible functionally (I am not sure what other limitations there are). The current filesystem metadata implementation, while limited, works. JDBC is a nice alternative to have. I am not so sure about implementing a hybrid - why not just use the JDBC one if you need more metadata? I will be closing this PR. It seems we should focus on promoting JDBC to the main repo for now. I still think long-term the JDBC provider should prove to be more resilient - better metadata storage and no recurring cross-platform problems, but perhaps a full replacement is not reasonable at this point. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/846#issuecomment-133422467
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
Aaa yes you noted this before and I missed it amongst other changes being
made. Jumping on this now
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37632011
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +import com.google.auto.value.AutoValue;
> +import com.google.common.collect.ImmutableList;
> +
> +@AutoValue
> +public abstract class Member {
> +
> + public abstract String id();
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + Member() {
I don't think this is needed?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37631196
Re: [jclouds-labs] JCLOUDS-985: Add members API (#196)
> +
> +@AutoValue
> +public abstract class CreateMember {
> +
> + @Nullable
> + public abstract String name();
> +
> + public abstract List peerURLs();
> +
> + public abstract List clientURLs();
> +
> + CreateMember() {
> + }
> +
> + @SerializedNames({ "name", "peerURLs", "clientURLs" })
> + public static CreateMember create(final String name, final List
> peerURLs, List clientURLs) {
You should probably make this method private.
Then, to be able to instantiate CreateMember, provide a builder using
auto-value similar to:
https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-heat/src/main/java/org/jclouds/openstack/heat/v1/options/CreateStack.java
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/196/files#r37631165
[jira] [Commented] (JCLOUDS-909) GCE NullPointer
[ https://issues.apache.org/jira/browse/JCLOUDS-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706424#comment-14706424 ] Akila commented on JCLOUDS-909: --- Getting the same error when using an existing network. The issue seems to be intermittent. > GCE NullPointer > --- > > Key: JCLOUDS-909 > URL: https://issues.apache.org/jira/browse/JCLOUDS-909 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.9.0 > Environment: linux >Reporter: Tomas Fecko > Labels: compute, gce > > After calling destroy on instance, NPE appeared. > Instance was started with network, I already created before, for all future > instances. > java.lang.NullPointerException > at > org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpNetworksAndFirewallsForGroup(GoogleComputeEngineService.java:138) > at > org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpIncidentalResourcesOfDeadNodes(GoogleComputeEngineService.java:128) > at > org.jclouds.compute.internal.BaseComputeService.destroyNodesMatching(BaseComputeService.java:274) > at > org.librade.comla.components.ComlaServerManagementComponent$8.run(ComlaServerManagementComponent.java:586) > at > org.fabric3.execution.runtime.PropagatingRunnable.run(PropagatingRunnable.java:33) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
