Re: [jclouds/jclouds-labs] Add tags to virtual network creation (#417)
Pushed to [master](http://git-wip-us.apache.org/repos/asf/jclouds-labs/commit/c9cd6eaf) and [2.0.x](http://git-wip-us.apache.org/repos/asf/jclouds-labs/commit/fd22d3ad). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/417#issuecomment-342403870
[jira] [Commented] (JCLOUDS-1111) AtmosClient.createFile should allow overwriting objects
[
https://issues.apache.org/jira/browse/JCLOUDS-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241346#comment-16241346
]
ASF subversion and git services commented on JCLOUDS-:
--
Commit b2ced53e165ecbea4188e2d2673a7ddb2f5a793d in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=b2ced53 ]
JCLOUDS-: Overwrite objects via remove and put
This partially reverts commit
e446b5b8b433327d8a11c0364abb051cff833431. AT Synaptic returns a
bogus error on with x-emc-force-overwrite:
HTTP 400, code=1012, message=There was a mismatch between the object
size and the specified extent size.
> AtmosClient.createFile should allow overwriting objects
> ---
>
> Key: JCLOUDS-
> URL: https://issues.apache.org/jira/browse/JCLOUDS-
> Project: jclouds
> Issue Type: New Feature
> Components: jclouds-blobstore
>Affects Versions: 1.9.2
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
> Labels: atmos
> Fix For: 2.1.0
>
>
> All other blobstore providers support overwrite semantics yet Atmos raises a
> 1006 error. Thus I believe we should send {{x-emc-force-overwrite}} for all
> {{AtmosClient.createFile}} calls which will improve the overwrite performance
> of {{AtmosBlobStore.putBlob}}. We could optionally allow the existing
> semantics by adding another field to {{PutOptions}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jclouds/jclouds] Use different content on overwrite. (#1154)
When testing blobstore overwrite behavior, jclouds should use a blob with different content (but same name). You can view, comment on, or merge this pull request online at: https://github.com/jclouds/jclouds/pull/1154 -- Commit Summary -- * Use different content on overwrite. -- File Changes -- M blobstore/src/test/java/org/jclouds/blobstore/integration/internal/BaseBlobIntegrationTest.java (5) -- Patch Links -- https://github.com/jclouds/jclouds/pull/1154.patch https://github.com/jclouds/jclouds/pull/1154.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1154
Re: [jclouds/jclouds-labs] Add tags to virtual network creation (#417)
nacx commented on this pull request.
> @@ -159,7 +159,7 @@ protected synchronized void
> createDefaultNetworkIfNeeded(String group, String lo
logger.debug(">> network options have not been configured. Creating
network %s(%s) and subnet %s(%s)", name,
defaultVnetAddressPrefix, name, defaultSubnetAddressPrefix);
-
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, properties);
+
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, null, properties);
Yes, We could do that and follow the same approach that we use for the
availability sets (although leaving a default network that will be reused per
resource group is not a big deal). Anyway, stuff for a different PR, right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/417#discussion_r149117921
Re: [jclouds/jclouds-labs] Add tags to virtual network creation (#417)
andreaturli commented on this pull request.
> @@ -159,7 +159,7 @@ protected synchronized void
> createDefaultNetworkIfNeeded(String group, String lo
logger.debug(">> network options have not been configured. Creating
network %s(%s) and subnet %s(%s)", name,
defaultVnetAddressPrefix, name, defaultSubnetAddressPrefix);
-
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, properties);
+
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, null, properties);
sure, that makes sense!
would it make sense to think about a default strategy to tag the
`virtualNetwork` so the clean up resources step can take advantage of it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/417#discussion_r149104066
Re: [jclouds/jclouds-labs] Add tags to virtual network creation (#417)
nacx commented on this pull request.
> @@ -159,7 +159,7 @@ protected synchronized void
> createDefaultNetworkIfNeeded(String group, String lo
logger.debug(">> network options have not been configured. Creating
network %s(%s) and subnet %s(%s)", name,
defaultVnetAddressPrefix, name, defaultSubnetAddressPrefix);
-
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, properties);
+
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, null, properties);
Using the provider-specific API. Without this change, there is no way to
configure the tags for a network.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/417#discussion_r149103400
Re: [jclouds/jclouds-labs] Add tags to virtual network creation (#417)
andreaturli commented on this pull request.
> @@ -159,7 +159,7 @@ protected synchronized void
> createDefaultNetworkIfNeeded(String group, String lo
logger.debug(">> network options have not been configured. Creating
network %s(%s) and subnet %s(%s)", name,
defaultVnetAddressPrefix, name, defaultSubnetAddressPrefix);
-
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, properties);
+
api.getVirtualNetworkApi(options.getResourceGroup()).createOrUpdate(name,
location, null, properties);
out of curiosity, how do you plan to use the `tags` is the
`CreateResourceThenCreateNodes` has them set to null?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/417#pullrequestreview-7234
Re: [jclouds/jclouds-labs] Add Azure KeyVault support -- vault management and certificate/key/secret operations (#416)
nacx commented on this pull request.
Thanks @jmspring! Huge effort!
I'm adding some general comments after a first review, but I still have to go
in deeper detail through the entire PR again:
* In the model classes, enforce immutable lists.
* Also try to use non-null collections and enforce presence where possible
(`tags` are an example of field where null is OK, but in most cases I'd say it
should be safe to enforce presence in collections).
* Use the `Date` type for fields that represent dates.
* In the API methods, remove all 404 fallbacks from PUT/POST/PATCH methods.
* Consider removing the TrueIf2xx class if jclouds already provides that
behavior by default.
Regarding the KeyVaultFilter. It looks like a clone of the
`ClientCredentialsSecretFlow` filter. Instead of overriding it to cover the MWS
use case, couldn't we configure the tests to use "localhost" for the vaultURL
so the default OAuthFilter can be used? What are the limitations that made you
change this?
Thanks for all the effort!
> @@ -411,7 +411,7 @@ private OSProfile createOsProfile(String computerName,
> Template template) {
private List createNetworkInterfaceCards(final String
nodeName, final String location,
AzureTemplateOptions options) {
- // Prefer a sorted list of NICs with the ones with public IPs first, to
+ // Prefer a sorted listVaults of NICs with the ones with public IPs
first, to
typo?
> + }
+ }
+
+ @AutoValue
+ public abstract static class SubjectAlternativeNames {
+ public abstract List dnsNames();
+
+ public abstract List emails();
+
+ public abstract List upns();
+
+ @SerializedNames({"dns_names", "emails", "upns"})
+ public static SubjectAlternativeNames create(final List dnsNames,
+ final List emails,
+ final List upns) {
+ return new AutoValue_Certificate_SubjectAlternativeNames(dnsNames,
emails, upns);
Enforce immutability
> +
+ @Nullable
+ public abstract SubjectAlternativeNames subjectAltNames();
+
+ @Nullable
+ public abstract String subject();
+
+ public abstract int validityMonths();
+
+ @SerializedNames({"ekus", "key_usage", "sans", "subject",
"validity_months"})
+ public static X509CertificateProperties create(final List
enhancedKeyUsage,
+ final List
keyUsage,
+ final
SubjectAlternativeNames subjectAltNames,
+ final String subject,
+ final int validityMonths)
{
+ return new
AutoValue_Certificate_X509CertificateProperties(enhancedKeyUsage, keyUsage,
subjectAltNames, subject, validityMonths);
Enforce immutability in all lists when present. Is there a reason to keep these
lists null, or could we better default to empty lists, to avoid the
null-collection anti-pattern?
> + @SerializedNames({"id", "provider"})
+ public static CertificateIssuer create(final String id,
+ final String provider) {
+ return new AutoValue_Certificate_CertificateIssuer(id, provider);
+ }
+ }
+
+ @AutoValue
+ public abstract static class IssuerAttributes {
+ @Nullable
+ public abstract String created();
+
+ public abstract boolean enabled();
+
+ @Nullable
+ public abstract String updated();
Can we use a `Date` type for the created and updated fields?
> + public abstract String id();
+
+ @SerializedNames({"contacts", "id"})
+ public static Contacts create(final List contacts,
+final String id) {
+ return new AutoValue_Certificate_Contacts(contacts, id);
+ }
+ }
+
+ @AutoValue
+ public abstract static class DeletedCertificateBundle {
+ @Nullable
+ public abstract CertificateAttributes attributes();
+
+ @Nullable
+ public abstract String bytes();
[minor] The method name suggests a return type of `byte[]`, but let's keep it
as-is if a string really makes more sense given the content of the field.
> + public static Contacts create(final List contacts,
+final String id) {
+ return new AutoValue_Certificate_Contacts(contacts, id);
+ }
+ }
+
+ @AutoValue
+ public abstract static class DeletedCertificateBundle {
+ @Nullable
+ public abstract CertificateAttributes attributes();
+
+ @Nullable
+ public abstract String bytes();
+
+ @Nullable
+ public abstract String deletedDate();
Change type to `Date`?
> + thumbprint
+ );
+ }
+ }
+
+ @Nullable
+ public abstract CertificateAttributes attributes();
+
+ @Nullable
+ public abstract String id();
+
+ @Nullable
+ public abstract Map
[jclouds/jclouds-labs] Add tags to virtual network creation (#417)
You can view, comment on, or merge this pull request online at: https://github.com/jclouds/jclouds-labs/pull/417 -- Commit Summary -- * Add tags to virtual network creation -- File Changes -- M azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/strategy/CreateResourcesThenCreateNodes.java (2) M azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/features/VirtualNetworkApi.java (3) M azurecompute-arm/src/test/java/org/jclouds/azurecompute/arm/features/VirtualNetworkApiLiveTest.java (2) M azurecompute-arm/src/test/java/org/jclouds/azurecompute/arm/features/VirtualNetworkApiMockTest.java (2) M azurecompute-arm/src/test/java/org/jclouds/azurecompute/arm/internal/BaseAzureComputeApiLiveTest.java (2) -- Patch Links -- https://github.com/jclouds/jclouds-labs/pull/417.patch https://github.com/jclouds/jclouds-labs/pull/417.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/417
[jira] [Created] (JCLOUDS-1353) AWS EC2 add support for Accelerated computing instance type
Andrea Turli created JCLOUDS-1353: - Summary: AWS EC2 add support for Accelerated computing instance type Key: JCLOUDS-1353 URL: https://issues.apache.org/jira/browse/JCLOUDS-1353 Project: jclouds Issue Type: Improvement Components: jclouds-compute Reporter: Andrea Turli Assignee: Andrea Turli Priority: Trivial Fix For: 2.1.0, 2.0.3 Support accelerated computing http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
