PS: I guess this was supposed to fix the
```
1.
2.
...
9.
0.
1.
...
```
issue?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/36#issuecomment-30368512
Honestly we should just rip out all of our CSS which has many issues with
pixel-width elements.
I'm not disagreeing, I just think that with _this particular_ change we're
worse off than we were before.
---
Reply to this email directly or view it on GitHub:
This is to avoid the line running into the next list item?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/38#issuecomment-30370475
+1 to merge and deploy this and close #38.
@andrewgaul: what would be a good way to address the restyling of the site in
general? Do we have access to some design resources - ASF or otherwise - that
could help here?
---
Reply to this email directly or view it on GitHub:
I would pick some Apache styling and go with that, instead of our own janky
style.
Are there some easy templates to use? Time to go searching in ASF-land, I
guess... ;-)
---
Reply to this email directly or view it on GitHub:
One suggestion, but looks good to me - +1.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/40#issuecomment-30394813
@@ -281,7 +281,7 @@ In addition to the create database instance example, by
going through the cloudd
## a id=autoscale/aWorking with Rackspace Autoscale
### a id=autoscale-intro/aIntroduction
-[Rackspace Autoscale](http://www.rackspace.com/cloud/autoscale/) takes the
work out of
-```
--Dhttps.proxyHost=proxy -Dhttps.proxyPort=3128
-```
Does setting the properties in the `overrides` do the same thing as specifying
the standard java.net [JVM proxy
properties](http://docs.oracle.com/javase/7/docs/technotes/guides/net/proxies.html)?
Because we have had threads on
I know that HttpURLConnection.setRequest() [2] doesn't allow PATCH.
I also know that we work around this in jclouds by setting the field
by reflection [3].
Have you been able to try this with the apachehc [1] driver? Does that
make any difference?
ap
[1]
@@ -227,6 +216,56 @@ protected HttpURLConnection convert(HttpRequest request)
throws IOException, Int
return connection;
}
+ /**
Implementation rather than a Javadoc comment?
---
Reply to this email directly or view it on GitHub:
+propagate(e);
+ }
+ try {
+Field methodField = null;
+while (connectionClass != null) {
+ try {
+ methodField = connectionClass.getDeclaredField(method);
+ } catch (NoSuchFieldException e) {
@nacx: Thanks! If we end up creating a follow-up commit, mention JCLOUDS-405
in the commit message?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/230#issuecomment-30461916
Thanks, @andrewgaul and @zack-shoylev! Squashed'n'rebased.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/35#issuecomment-30463219
jclouds-java-7-pull-requests #931 UNSTABLE
Looks like a spurious [test
failure](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/931/testReport/).
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/231#issuecomment-30464208
@zack-shoylev: I've reviewed the POMs only, assuming that all the other files
are unchanged. POMs look fine; just wondering whether there are any
APIs/providers in one of the labs projects that will now need the groupId of
a trove dep to be updated?
Otherwise, +1 - looks good to me.
---
Reply
+
+ /**
+* @param id
+*firewall rule ID
+*/
+ public ListEgressFirewallRulesOptions id(String id) {
+ this.queryParameters.replaceValues(id, ImmutableSet.of(id + ));
+ return this;
+ }
+
+ /**
+* @param networkId
+*the id of network of the
+
+ /**
+* @param networkId
+*the id of network of the firewall services
+*/
+ public ListEgressFirewallRulesOptions networkId(String networkId) {
+ this.queryParameters.replaceValues(networkid,
ImmutableSet.of(networkId + ));
+ return this;
+ }
+
+
+ ListEgressFirewallRulesOptions options = new
ListEgressFirewallRulesOptions();
+ return options.pageSize(pageSize);
+ }
+
+ /**
+ * @see ListEgressFirewallRulesOptions#accountInDomain
+ */
+ public static ListEgressFirewallRulesOptions
+
+ /**
+* {@inheritDoc}
+*/
+ @Override
+ public ListEgressFirewallRulesOptions accountInDomain(String account,
String domain) {
+ return
ListEgressFirewallRulesOptions.class.cast(super.accountInDomain(account,
domain));
+ }
+
+ /**
+* {@inheritDoc}
+
Thanks, @hyeonu! Do you have the output of a live test run that demonstrates
this in action?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/229#issuecomment-30470290
See comments at #229.
jclouds-pull-requests #466 UNSTABLE
Looks like a
[timeout](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/org.apache.jclouds.common$azure-common/466/testReport/junit/org.jclouds.azure.storage.filters/SharedKeyLiteAuthenticationTest/testIdempotent/)
unrelated
+* /p
+* When a claim expires, it is released. If the original worker failed to
process the message, another client worker
+* can then claim the message.
+* /p
+* Note that claim creation is best-effort, meaning the worker may claim
and return less than the requested
+* When a claim expires, it is released. If the original worker failed to
process the message, another client worker
+* can then claim the message.
+* /p
+* Note that claim creation is best-effort, meaning the worker may claim
and return less than the requested number
+
+* from the original TTL). The server resets the age of the claim and
applies the new TTL.
+*
+* @param claimId Specific claim ID of the message to get.
+* @param ttl The ttl attribute specifies how long the server waits
before releasing the claim. The ttl value
+*
+* @param ttl The ttl attribute specifies how long the server waits
before releasing the claim. The ttl value
+*must be between 60 and 43200 seconds (12 hours). You
must include a value for this attribute in
+*your request.
+*/
+ //
+import static com.google.common.base.Preconditions.checkNotNull;
+import static com.google.common.collect.Iterables.transform;
+import static com.google.common.collect.Lists.newArrayList;
+import static
org.jclouds.openstack.marconi.v1.functions.ParseMessagesToStream.MessageWithHref;
+ return claimWithHref.toBuilder()
+ .id(claimId)
+ .messages(messages)
+ .build();
+ }
+ };
+ private final ParseJsonClaimWithHref json;
+
+ @Inject
+ ParseClaim(ParseJsonClaimWithHref json) {
+ this.json =
@@ -58,4 +62,19 @@
public static final Location GOOGLE_PROVIDER_LOCATION = new
LocationBuilder().scope(LocationScope.PROVIDER).id
(GCE_PROVIDER_NAME).description(GCE_PROVIDER_NAME).build();
+
+ /**
+* The key we look for in instance metadata for the URI for the
@@ -34,6 +34,10 @@
*/
public static final String GOOGLE_PROJECT = google;
+ public static final String CENTOS_PROJECT = centos-cloud;
+
+ public static final String DEBIAN_PROJECT = debian-cloud;
Applies to all of these properties, but...no need for `public`? These are in an
@@ -129,6 +139,21 @@ public
GoogleComputeEngineServiceAdapter(GoogleComputeEngineApi api,
Hardware hardware = checkNotNull(template.getHardware(), hardware
must be set);
checkNotNull(hardware.getUri(), hardware must have a URI);
+
@@ -199,6 +232,30 @@ public String apply(Integer input) {
return new NodeAndInitialCredentialsInstanceInZone(instanceInZone,
instanceInZone.slashEncode(), credentials);
}
+ private Disk createBootDisk(Template template, String instanceName) {
+ URI imageUri =
.status(toPortableNodeStatus.get(input.getStatus()))
.tags(tags)
.uri(input.getSelfLink())
.userMetadata(input.getMetadata().getItems())
.group(group)
.privateAddresses(collectPrivateAddresses(input))
.status(toPortableNodeStatus.get(input.getStatus()))
.tags(tags)
.uri(input.getSelfLink())
.userMetadata(input.getMetadata().getItems())
.group(group)
.privateAddresses(collectPrivateAddresses(input))
@@ -42,6 +43,9 @@
private OptionalString networkName = Optional.absent();
private SetInstance.ServiceAccount serviceAccounts =
Sets.newLinkedHashSet();
private boolean enableNat = true;
+ private SetPersistentDisk disks = Sets.newLinkedHashSet();
Do we need a sorted set here?
@@ -97,6 +103,24 @@ public GoogleComputeEngineTemplateOptions
serviceAccounts(SetServiceAccount se
}
/**
+* @see #getDisks()
+* @see
org.jclouds.googlecomputeengine.domain.InstanceTemplate.PersistentDisk
+*/
+ public GoogleComputeEngineTemplateOptions
this.mode = checkNotNull(mode, mode);
this.source = checkNotNull(source, source);
this.deviceName = deviceName;
this.deleteOnTerminate = deleteOnTerminate;
+ this.boot = boot;
If `deleteOnTerminate` and `boot` are `Boolean`s and not `boolean`s,
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
@@ -129,6 +139,21 @@ public
GoogleComputeEngineServiceAdapter(GoogleComputeEngineApi api,
Hardware hardware = checkNotNull(template.getHardware(), hardware
must be set);
checkNotNull(hardware.getUri(), hardware must have a URI);
+
+ .addHeader(Authorization, Bearer + TOKEN)
+ .payload(payloadFromStringWithContentType({\name\:\ +
instanceName + - + GCE_BOOT_DISK_SUFFIX + \,
++ \sizeGb\:10},
+
.payload(staticPayloadFromResource(/image_list_single_page.json)).build();
+ public static final HttpRequest LIST_DEBIAN_IMAGES_REQUEST = HttpRequest
+ .builder()
+ .method(GET)
+
.endpoint(https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images;)
@@ -213,4 +224,20 @@ private void assertInstanceEquals(Instance result,
InstanceTemplate expected) {
assertEquals(result.getName(), expected.getName());
assertEquals(result.getMetadata().getItems(), expected.getMetadata());
}
+
+ @AfterClass(groups = { integration, live
.build()
)
.tags(Instance.Tags.builder().fingerprint(abcd).addItem(aTag).build())
.metadata(Metadata.builder()
- .items(ImmutableMap.of(aKey, aValue))
+
@@ -23,8 +22,9 @@
type: PERSISTENT,
mode: READ_WRITE,
deviceName: test,
- source:
https://www.googleapis.com/compute/v1beta16/projects/myproject/zones/us-central1-a/disks/test;,
- index: 0
+ source:
@@ -41,7 +41,15 @@
{
key: aKey,
value: aValue
- }
+ },
+ {
+ key: jclouds-image,
+ value:
https://www.googleapis.com/compute/v1/projects/centos-cloud/global/images/gcel-12-04-v20121106;
+ },
@@ -28,8 +27,9 @@
type: PERSISTENT,
mode: READ_WRITE,
deviceName: test,
- source:
https://www.googleapis.com/compute/v1beta16/projects/myproject/zones/us-central1-a/disks/test;,
- index: 0
+ source:
+
slashEncodedIds.getSecondId());
+ if
(instance.getMetadata().getItems().get(GCE_DELETE_BOOT_DISK_METADATA_KEY).equals(true))
{
+OptionalAttachedDisk disk = tryFind(instance.getDisks(), new
@@ -199,6 +232,30 @@ public String apply(Integer input) {
return new NodeAndInitialCredentialsInstanceInZone(instanceInZone,
instanceInZone.slashEncode(), credentials);
}
+ private Disk createBootDisk(Template template, String instanceName) {
+ URI imageUri =
@@ -97,6 +103,24 @@ public GoogleComputeEngineTemplateOptions
serviceAccounts(SetServiceAccount se
}
/**
+* @see #getDisks()
+* @see
org.jclouds.googlecomputeengine.domain.InstanceTemplate.PersistentDisk
+*/
+ public GoogleComputeEngineTemplateOptions
Given the number of
```
https://www.googleapis.com/compute/v1beta16/ -
https://www.googleapis.com/compute/v1/
```
changes here, would it make sense to extract that as a constant for next time..?
---
Reply to this email directly or view it on GitHub:
@@ -58,4 +62,19 @@
public static final Location GOOGLE_PROVIDER_LOCATION = new
LocationBuilder().scope(LocationScope.PROVIDER).id
(GCE_PROVIDER_NAME).description(GCE_PROVIDER_NAME).build();
+
+ /**
+* The key we look for in instance metadata for the URI for the
In general, I'm thinking I'd like to defer the refactoring/constant-izing of
the API version string/etc to a separate
commit, if that's ok.
Yes, sure...that's what I was thinking, too. Or integrate it in the next chunk
of work.
---
Reply to this email directly or view it on GitHub:
+ *
+ * @see a href=
+ *
http://download.cloud.com/releases/3.0.6/api_3.0.6/root_admin/listEgressFirewallRules.html;
+ * /
+ * @author Hyeonu Jeong
+ */
+public class ListEgressFirewallRulesOptions extends AccountInDomainOptions {
+
+ public static final
+ *
+ * @see a href=
+ *
http://download.cloud.com/releases/3.0.6/api_3.0.6/root_admin/listEgressFirewallRules.html;
+ * /
+ * @author Hyeonu Jeong
+ */
+public class ListEgressFirewallRulesOptions extends AccountInDomainOptions {
+
+ public static final
Here is live test results(test only testCreateEgressFirewallRule and
testListEgressFirewallRules):
Looks good, thanks!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/229#issuecomment-30489332
@andrewgaul, @zack-shoylev: Sorry to ping again, but if you could kindly have a
look at the two additional commits I added since your review, that'd be great,
thanks...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/35#issuecomment-30527960
Given this, do you think we should revert the patch [2]? It only
extends the reflection stuff to properly set the method in HTTPS
connections, so in practice I think the code could remain. If we keep
the patch, at least we would be able to use PATCH requests with a body
over HTTPS, as the
The driver integration tests, are failing randomly (:() and still
haven't found a pattern. Tests only fail sometimes (not always the
same tests) and still haven't been able to successfully debug them.
Could you submit a work-in-progress PR that we can use to trigger the
pull request builders
Is there any way to make this change in two stages:
1. Add the ability to use ByteSource but remain backwards compatible, whilst
deprecating the `getInput` etc. methods related to InputSupplier
2. Remove support for InputSupplier (if deemed necessary) in 1.8
?
---
Reply to this email directly
@@ -66,14 +67,25 @@ public T payload(Payload payload) {
/**
* @see HttpMessage#getPayload()
*/
+ @Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
@@ -25,6 +25,7 @@
/**
* @author Adrian Cole
*/
+@Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/234/files#r8356744
public static ByteArrayPayload newByteArrayPayload(byte[] data) {
return new ByteArrayPayload(checkNotNull(data, data));
}
+ public static ByteSourcePayload newByteSourcePayload(ByteSource data) {
+ return new ByteSourcePayload(checkNotNull(data, data));
+ }
+
+
public static StringPayload newStringPayload(String data) {
return new StringPayload(checkNotNull(data, data));
}
+ @Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
@@ -29,6 +29,7 @@
/**
* @author Adrian Cole
*/
+@Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/234/files#r8356749
+ } catch (IOException e) {
+ throw Throwables.propagate(e);
+ }
+ }
+
+ @Override
+ public boolean isRepeatable() {
+ return true;
+ }
+
+ /**
+* if we created the stream, then it is already consumed on close.
+*/
+ @Override
+ public
@@ -27,6 +27,7 @@
*
* @author Adrian Cole
*/
+@Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/234/files#r8356750
@@ -28,6 +28,7 @@
/**
* @author Adrian Cole
*/
+@Deprecated
Add `@deprecated` Javadoc to describe alternative(s)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/234/files#r8356748
PayloadBlobBuilder payload(byte[] payload);
/**
+*
+* @param payload
+* payload you wish to construct the {@link Blob} with.
+*/
+ PayloadBlobBuilder payload(ByteSource byteSource);
+
+ /**
*
* @param payload
* payload
but cannot see a backwards-compatible way to do this.
I feared as much. *sigh*. Thanks for explaining.
For which release are we targeting this? Would be interested to hear thoughts
from others on this one...
---
Reply to this email directly or view it on GitHub:
*
* @param payload
* payload you wish to construct the {@link Blob} with.
+* @deprecated see payload(ByteSource))
Duplicate `)`. How about use {@code
payload(ByteSource.wrap(stringPayload.getBytes(Charsets.UTF_8))}?
---
Reply to this email directly or view it
@@ -26,7 +26,9 @@
* a different encoding, please use {@link ByteArrayPayload}.
*
* @author Adrian Cole
+ * @deprecated see newPayload(ByteSource)
newPayload in which class?
---
Reply to this email directly or view it on GitHub:
public static ByteArrayPayload newByteArrayPayload(byte[] data) {
return new ByteArrayPayload(checkNotNull(data, data));
}
+ public static ByteSourcePayload newByteSourcePayload(ByteSource data) {
+ return new ByteSourcePayload(checkNotNull(data, data));
+ }
+
+
The best thing I can think of for now that would be backwards compatible is:
1. Keep Payload a subinterface of InputSupplier for now
2. Add an `asByteSource` method to Payload that would return a view of a
Payload as a ByteSource
3. Deprecate `Payload.getInput` with a warning to switch to
For 1.7, add an openStream() throws IOException method and deprecate getInput
without a checked exception.
Good idea! +1 from me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/233#issuecomment-30683934
Pending PR builders +1, looks good to me. Thanks, @andrewgaul!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/235#issuecomment-30693556
@jdaggett: Is the underlying Swift API going to go away? In that case, I guess
it wouldn't be bad to warn users of that in advance, independently of whether
we have the jclouds replacement in place..?
---
Reply to this email directly or view it on GitHub:
My take: deprecate early, rather than late, even if replacement functionality
is not already there. I realize not
everybody would agree with me.
Or, as a halfway house, add a Javadoc warning that this code will soon be
deprecated and then removed? Won't create a compiler deprecation warning
jclouds-java-7-pull-requests #945 UNSTABLE
Looks like [real test
failures](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/org.apache.jclouds$jclouds-core/945/testReport/),
I'm afraid :-( But I guess the PR has been updated? I see new PR builds
running...
---
Reply to this
jclouds-pull-requests #483 UNSTABLE
Spurious [test
failure](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/org.apache.jclouds$jclouds-compute/483/testReport/junit/org.jclouds.compute.util/ConcurrentOpenSocketFinderTest/testChecksSocketsConcurrently/).
Thanks, @andrewgaul!
---
But I'm seeing some problems when running against the transient and
filesystem providers.
For the transient blobstore, I see the following:
Cannot retry after server error, command has exceeded retry limit 5:...
For the filesystem blobstore, I get an error saying that it can't
find the
I can submit the changes in another PR. WDYT?
Works for me. Or rework this PR - whatever you prefer ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/237#issuecomment-30766557
I sense a Wiki page coming up..? ;-)
Thanks for the questions, Everett - looking forward to learning more
about the background to these, too!
ap
Ok, waiting to see if chef is actually fixed - if it is, I'll recut the
release today. If not, I'll do it either tomorrow or Thursday. I'm ill
today (blech) and traveling tomorrow, so scheduling is a bit whacky. =)
If you need any help with the release, let me know - I probably could
make
+1 - looks good to me. I'm guessing the live tests came back OK?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/66#issuecomment-30773363
I'll be replacing the tag - I'd assumed we'd do this off master and then
cut 1.7.x branches afterwards, but I'm open to either way.
The first 1.6.0 release commits were also on the 1.6.x branch and not
on master [1, 2], so unless we see a good reason to change that
pattern I'd say we create
now only has one job left (jclouds-karaf)? Has anyone deleted the
others intentionally? If not, I'll open a support ticket with CloudBees
to see where they might have gone...
Looks like they've disappeared from disk?! I've asked Ryan Campbell
from CloudBees to restore them [1].
ap
[1]
Checkstyle is clean - +1, looks good to me!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/65#issuecomment-30777617
Also, the reason I was seeing the failures against transient and
filesystem blobstores was that I was trying to do signed puts. I
changed that to do simple puts and it worked just fine.
Some more polishing of the code and I'll send this out for review.
Sorry, missing some context here. Is this
PS: Do we also need a [CANCEL][VOTE] email on the other thread? Is
there any kind of difference between [CLOSED] and [CANCEL]? Can't
seem to find anything in the ASF docs that would explain the
difference...
ap
Doh...could have spotted that too :-( +1 - looks good to me.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/68#issuecomment-30813672
+ try {
+ AutoscaleApi autoscaleApi = api(server.getUrl(/).toString(),
rackspace-autoscale, overrides);
+ PolicyApi api = autoscaleApi.getPolicyApiForZoneAndGroup(DFW,
groupId1);
+
+ FluentIterableScalingPolicyResponse scalingPolicyResponse =
+ try {
+ AutoscaleApi autoscaleApi = api(server.getUrl(/).toString(),
rackspace-autoscale, overrides);
+ WebhookApi api =
autoscaleApi.getWebhookApiForZoneAndGroupAndPolicy(DFW, 1234567890,
321456);
+
+ FluentIterableWebhookResponse webhooks =
+
+ FluentIterableWebhookResponse webhooks =
api.create(ImmutableList.of(
+
Webhook.builder().name(PagerDuty).metadata(ImmutableMap.String,
Objectof(notes, PagerDuty will fire this webhook)).build(),
+
Haven't checked the semantics of the tests in detail, but bar a couple of minor
comments, the code looks OK.
jclouds-labs-openstack-pull-requests #120 FAILURE
Is there any reason this would need to be in the jclouds repo? There's nothing
similar in there right now. Would
[jclouds-examples](https://github.com/jclouds/jclouds-examples) perhaps be a
more suitable home for this?
That already contains a collection of code that _uses_ jclouds, which seems
Out of curiosity, Does anyone know why we are explicitly configuring
the memory for the integration tests [1], but not for the unit and
live tests?
Can we just remove that line?
Do you have any information on what effect that change with have? Does
it speed things up? Are there any problems
I do not want the perfect to be the enemy of the good.
I agree, but I think we can still put a little thought into where this and,
indeed (as you say) related types of admin tools should go before we need to
accuse ourselves of striving for immediate perfection. I don't think the code
needs
With #239 [1], we'll hopefully be able to get an interesting and
useful benchmarking tool from Maginatics out to the wider jclouds
audience. Some debate going on in the issue, though, about where the
right place for this and related administrative tools and utilities
should be.
I
BlobStoreCli replaces some uses of the existing karaf-based jclouds-cli
using really-executable-jar. This offers a more intuitive user
experience and slimmer binary size.
This is probably a different discussion, but it sounds like the
feeling is that Karaf is not sufficiently improvable to
jclouds-labs-openstack-pull-requests #125 UNSTABLE
Still one [failing
I added a blurb about updating examples
Thanks!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/26#issuecomment-30881546
301 - 400 of 1315 matches
Mail list logo
