- I did spend quite a lot of time on this, but I find that the
structure and set of idiom secrecies of this specific project are a bit
complex.
(Y)
On Nov 21, 2014, at 7:05 PM, Adrian Cole adrian.f.c...@gmail.com
wrote:
Yes, I know - I tried tracking it down myself. I find the jClouds
static final long DEFAULT_MAX_PERIOD = 1000l;
On Fri, Nov 21, 2014 at 6:02 AM, Yaron Rosenbaum
yaron.rosenb...@gmail.com wrote:
Adrian,
Thank you!
BTW. What are the defaults?
(Y)
On Nov 20, 2014, at 6:08 PM, Adrian Cole adrian.f.c...@gmail.com wrote:
Hi, Yaron.
I believe you are looking
Hi, David.
Can you search for an issue wrt loadbalancer support?
https://issues.apache.org/jira/browse/JCLOUDS
We do have a rusty abstraction, but it needs to be redone. Not only
are there the clouds you mentioned, but also cloudstack, google
compute, etc. This effort needs a dev who will
Yes, I know - I tried tracking it down myself. I find the jClouds code a bit
hard to comprehend.
understood.. try maintaining it :)
BTW
50-1000 msecs are insanely small numbers IMO. No wonder AWS returned errors
yeah, it is silly for spot instances, but some clouds start vms in
well under 30
Hi, Yaron.
I believe you are looking to override these two from
ComputeServiceProperties. Use ContextBuilder.overrides (or set java
system properties) to do so!
Hope this helps,
-A
/**
* Initial period between the ComputeService's node polls.
Subsequent periods increase exponentially
Hi, Eyal!
I will give you a short answer.
In current design, jclouds contexts are relatively expensive to create.
They are designed to be shared, and outlive sessions. If you have a problem
with token renewal, that would be a bug.
Hope this helps!
-A
On Nov 19, 2014 5:05 AM, Zitony, Eyal
looks like there is. Let's keep discussion in that jira for now!
endpoint set up for the same blobstore
(to use the openstack-swift provider). Are there any ideas I should try in
the meantime?
Thank you.
On Mon, Nov 17, 2014 at 3:26 PM, Adrian Cole adrian.f.c...@gmail.com
wrote:
Ok. I will add it :)
--
Daniel Hsueh -- mailto:daniel.hs...@seagate.com
it is in the main repo now and will be in any next release of jclouds.
On Tue, Nov 18, 2014 at 8:13 AM, Vineet Saini switchcod...@gmail.com wrote:
So I should be pick this fix from 1.8.2 snapshot release only, is that
correct? Also when it will be pushed to repo?
On Tue, Nov 18, 2014 at 9:58
Before we go more into this, is it possible for you to use the
openstack-swift api present in 1.8.1. Swift has been overhauled and the
old codebase is on the way out.
-A
Ok. I will add it :)
Hi, Vineet.
Can you do a search and see if this issue already exists? If so, vote
it up, if not please add it?
https://issues.apache.org/jira/browse/JCLOUDS
Thanks,
-A
On Mon, Nov 17, 2014 at 1:13 PM, Vineet Saini switchcod...@gmail.com wrote:
Hi,
I'm trying to create node in AWS EC2. But
TL;DR;
jclouds will stop maintaining vcloud in 1.8.x. We will remove vcloud
(and the vcloud-director labs provider) in version 1.9.0.
Our vcloud codebase is old, unsupported by cloud providers and a
crippling maintenance debt on the project. If we want jclouds to
endure, we have to make
I meant apis/vcloud/src/test/java
Hi! Best answer I can give today (as on a ferry) is look at the source
repository under apis/vcloud/test. There will be tests with a suffix
LiveTest. You may find an example in one of those, if exists.
Hope the breadcrumbs help.
-A
Hi, Anthony. There is no synchronized, or mutex code in the current
filesystem implementation. There are also no multithreaded tests to
show it doesn't need that. In other words, I would use it only from a
single thread, and synchronize externally. That said, you can always
raise a pull request to
Hi, Colin.
VirtualBox has been dropped from jclouds labs as of version 1.9 [1].
We've stopped investing time in virtualization providers such as
virtualbox or vsphere as they take inordinate amount of maintenance
which displaces our ability to maintain cloud providers. I would look
into other
2.0 snapshot has problems with firewall rules which prevent port 22 from
being reached. This will be fixed before that code is promoted as version
1.9.
-A
On Nov 11, 2014 8:42 PM, Sunil Shah su...@mesosphere.io wrote:
Hey User list,
We're seeing problems since upgrading to 2.0.0-SNAPSHOT from
Hi, Gabriel. I'll give you one set of answers. Maybe you'll get another :)
- Is the filesystem API considered production safe or only suggested for
testing/debugging?
Put a gun to my head, and I'd say no. For example, it is unsafe to run
multithreaded as there are race conditions in the impl
the practical implications of this?
(Y)
On Oct 27, 2014, at 4:06 PM, Adrian Cole adrian.f.c...@gmail.com wrote:
You've hit quite the edge case! Basically, there were instances returned
from the create call that were not returned from the describe call. Eventual
consistency, in other words
You've hit quite the edge case! Basically, there were instances returned
from the create call that were not returned from the describe call.
Eventual consistency, in other words.
Hi, 安仲奇!
So, I wouldn't say jclouds is android friendly, yet. It still uses a lot of
reflection and we don't have a test module to ensure any level of
compatibility.
That said, we can improve upon this over time for sure. First steps I would
take is to use 1.8.1 (coming out this week), the
, Adrian Cole wrote:
Actually, it seems the 2.0 branch has started to use java 7 constructs
internally, which will make jclouds definitely incompatible with android.
For example, it is ok for code to expose alternate paths that use java 7 or
even 8 (ex how okio still works is that these methods
Nope that's it. Same process for the okhttp one (if you wish to try it)
-A
On Oct 3, 2014 9:15 AM, Yury Kats yuryk...@yahoo.com wrote:
Thanks, got them.
So to use those drivers, all I need to do is add
.modules(ImmutableSet.of(new
ApacheHCHttpCommandExecutorServiceModule()))
Good idea, bk. Looking forward to what folks are interested in.
-A
On Oct 3, 2014 7:17 AM, Bk Lau bklau2...@gmail.com wrote:
Hi folks:
Docker is all the rage today[1]...
I have started recently to use jClouds's implementation of Docker Remote
API[2].
Noticed that jclouds's binding to the
OkHttpCommandExecutorServiceModule()))
.buildApi(KeystoneApi.class);
Which makes me think the driver is not being utilized, regardless of the
.modules() modifier.
How can I confirm what driver is actually being used to make the connection?
On 10/3/2014 12:44 PM, Adrian Cole wrote
, are there any other reasons for me to look at
okhttp or apachehc drivers?
Thanks again!
On 10/3/2014 1:22 PM, Adrian Cole wrote:
That sounds very strange indeed. I don't have an answer for how to
verify which driver is in use, except maybe put a breakpoint.
PS I had a quick look at the code [1
Plus, if you are using google storage, it will automatically use SPDY :P
On Fri, Oct 3, 2014 at 12:05 PM, Adrian Cole adrian.f.c...@gmail.com wrote:
Glad to hear it worked.
Disclaimer: I am a committer on okhttp.
OkHttp acknowledges that the JRE HttpUrlConnection class has not been
awesome
This sounds like an http transport concern, Yury.
Perhaps you can try a different driver, such as our okhttp one? Not saying
this will automatically solve, but I am pretty sure the answer will be in
the http driver. We may have a singleton somewhere in the default driver
(which we could look
at 5:52 PM, Adrian Cole adrian.f.c...@gmail.com wrote:
jclouds currently doesn't have a direct path to the outputstream (or
channel), and even if it did, things mentioned by gaul would still be
true (ex. may need content-length up front).
jclouds doesn't have a direct path to becoming netty, so
jclouds currently doesn't have a direct path to the outputstream (or
channel), and even if it did, things mentioned by gaul would still be
true (ex. may need content-length up front).
jclouds doesn't have a direct path to becoming netty, so I wouldn't
get too excited about full-bore async.
31 matches
Mail list logo
