Hi Darren,
The Rackers or the Googlers can probably help more but to answer as best
I can--
As you probably know the usual jclouds pattern is to treat different
versions of an API as clean-room impls, so the v3.0 codebase wouldn't
share much if any code with the v2.0 codebase. If a user wan
Yes, do it!
Best
Alex
On 26/06/2015 11:18, Ignasi Barrera wrote:
Unless anyone says the opposite Today I plan to push the Google
Compute Engine provider [1] to the main repo.
Those subscribed to the commits@ list will experience some massive
commit notifications, as we'll keep the commit his
Hi All-
I'm noticing something strange with google-compute-engine and
`TemplateOptions.authorizePublicKey(key)`.
I assumed this is meant to allow a user to supply an *additional* public
key to be authorized on the machine. Is this right?
In google-compute-engine, if you set this, jclouds
Great idea Ignasi. Speaking as a contributor it's sad when I offer a PR
and it doesn't land in a release for many months. Of course I
understand the overhead in cutting a release and the desire to keep the
bar high but I think the balance would be better served with frequent
releases. And
Congrats and thanks!
--A
On 14/11/2016 17:02, Ignasi Barrera wrote:
The vote is now closed, and with 4 binding +1s (*) and no -1s, we're ready
to release!
(*) One vote was posted by mistake to the DISCUSS thread:
http://markmail.org/message/fr5o4ahodpr5mznx
On 15 November 2016 at 00:54, Z
Hi Spandan, All-
Just to say I'm very excited about this. I've long since wanted to be
able to have an async TemplateBuilder.build() and
ComputeService.createNodesInGroup() and not using NIO has felt messy and
inefficient. So thanks!
I agree with Ignasi's suggestions -- in particular that
Can we keep backwards compatibility at image selection time by saying if
an imageId is supplied by caller but isn't found, search for
regionId+":"+imageId? (I'm assuming that the fix changes behaviour so
that jclouds's map of image IDs will now use cloudstack
zoneId+":"+templateId as key, in
Thanks Geoff, and Jclouds team, and Markus for the contribution.
FWIW regretfully I'd rather jclouds *didn't* do this. Personally I
don't see benefits to Apache Brooklyn and I *do* see it increasing our
dependency hell -- as ugly as shading is, it spares us that problem.
Given that it soun
+1 & TY!
On 11/01/2021 14:40, Andrew Phillips wrote:
Andrew Gaul. is quite more active and involved in the project than I
am, so
I'd like to propose him as the new chair for the project.
+1 - thanks for the suggestion!
@Gaul: glad to hear that you might be available for this!
A belated Ha
As a member of the Apache Brooklyn PMC I'd be pleased to see jclouds
sustained a bit longer.
Increasingly in AB people are using custom containers (eg AWS CLI),
terraform, helm, and other tools to drive creation, but for well-behaved
VMs without much thought jclouds is usually simpler than any of
+1
good clean solution in this case and I bet it will be useful elsewhere
hopefully this ProviderException hierarchy in turn extends RuntimeException
--A
On 14/11/2013 09:09, Ignasi wrote:
Hi!
Recently, to deal with a corner case in Softlayer, a patch [1] was
submitted to create a specific
1:02, Alex Heneveld
wrote:
+1
good clean solution in this case and I bet it will be useful elsewhere
hopefully this ProviderException hierarchy in turn extends RuntimeException
--A
On 14/11/2013 09:09, Ignasi wrote:
Hi!
Recently, to deal with a corner case in Softlayer, a patch [1]
+1
Best,
Alex
On Nov 15, 2013 4:22 PM, "Everett Toews"
wrote:
> On Nov 14, 2013, at 12:18 PM, Andrew Bayer wrote:
>
> > So with 1.6.3 aiming to be out next week, I'd like to put a target date
> on
> > 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> > to do the first R
Hi folks-
The GCE identity parse fix ([2] and [3]) did not get backported. This
will cause problems for many users of GCE.
I've created a PR for this backport now at [1].
Would it be possible to cut a new RC for 1.6.3 including this? I know
it's work but GCE is the fastest cloud that I've
Thanks Andrew P.
Sorry for posting to the wrong thread. There is something funny in how
[THREAD] prefixes are getting ignored (just mentioning in case anyone
else has that) somewhere between Thunderbird and Google Mail.
I've also backported the oauth live tests fix at [4] fixing live test
> yes in my PR I've replaced the way we pass the creadential, now it
needs to
> point to your filesystem, something like /home/$USER/my/key
Is this going to break backwards compatibility?
I realize it's in labs so maybe that's okay, and certainly passing the
entire key in a property is not i
side question -- GCE currently presents itself as an api (implementing
ApiMetadata) rather than a provider. is there a reason why? it seems
to me it should be a provider.
as for it leaving labs, having used the library a lot, i'd suggest it be
promoted now -- kudos to abayer and dralves fo
// cross-posting to dev@jclouds and brooklyn-dev as I think this is a
weird jclouds edge case
In Brooklyn we're seeing what looks like a funky jclouds VM setup issue
-- see original mail from David Toy below. The error is:
1) IllegalStateException on node us-east-1/i-15958144:
java.lang.Il
search
> shows that the error appears when you try to execute a script file that is
> open for writing.
>
> I'm wondering why the file is still open when the script is executed and it
> seems that you're right Alex.
>
> Out of curiosity, which SSH driver is being us
+1 -- Good solution Ignasi. Makes the functionality available while
avoiding a tricky dependency problem down the line.
--A
On 28/08/2014 17:33, Ignasi Barrera wrote:
Hi devs!
I've been having a look at the vSphere pull request [1], and wanted to
share some challenges it presents, and hop
jclouders-
While doing a license audit on Apache Brooklyn -- which uses Apache
jclouds -- @frontiertown (cc'd) discovered an LGPL dependency coming
from jclouds: *net.java.dev.jna:jna* -- see [1] and [2] for the license
of this. (I think the same may be true for the one other in the jna
fam
21 matches
Mail list logo
