Re: [jclouds-labs] Profitbricks REST - Volume API (#233)

[Reijhanniel Jearl Campos]

Binder tests, :heavy_check_mark: ! Unless @nacx has further comments, this 
LGTM! 

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/233#issuecomment-185511676

Re: [jclouds-labs] Refactored ProfitBricks locations to not rely on existing DataCenters (#235)

[Reijhanniel Jearl Campos]

Man you're a magician! :+1: 

The way you did the *create-datacenter-if-not-exist* was awesome. Wasn't 
familiar with how `CreateNodesWithGroupEncodedIntoNameThenAddToSet` worked 
before, and your [custom 
impl](https://github.com/jclouds/jclouds-labs/pull/235/files#diff-2de75f6f337c46cc3ee37511896f795fR57)
 gave me a lot of context.

Just one thing I'd like to ask, how did you get the correct ISO codes for the 
locations? (i.e.: `DE-BW`, `DE-HE`, `US-NV`)? I remember 
[asking](https://botbot.me/freenode/jclouds/2014-12-20/?msg=28000713=1) 
for this before (and still couldn't find a list now) and was only able to 
determine, `DE` for Germany, etc. Did you manually 
[match](https://www.iso.org/obp/ui/#iso:code:3166:DE), like look at a map or 
something? :smiley: 

[nit] Just some typos in the 
[`TemplateWithDataCenter`](https://github.com/jclouds/jclouds-labs/pull/235/files#diff-3db81757e47ede67f080ce2a0d44aef1R43).

This **definitely** needs to get merged before the promotion. Some serious 
refactoring stuff you did here. Thanks @nacx !

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/235#issuecomment-185504039

[jira] [Commented] (JCLOUDS-1079) Floating IPs should be public in openstack-nova provider

[Josef Cacek (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15151388#comment-15151388
 ] 

Josef Cacek commented on JCLOUDS-1079:
--

PR: https://github.com/jclouds/jclouds/pull/921

[~nacx] Could you review it, please?

> Floating IPs should be public in openstack-nova provider
> 
>
> Key: JCLOUDS-1079
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1079
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-compute
>Affects Versions: 2.0.0
>Reporter: Josef Cacek
>  Labels: openstack-nova
>
> Floating IPs from private address blocks are not presented as public address 
> of a NodeMetadata after refreshing it. (They are only configured as public 
> addresses when creating a new Node).
> * The OpenStack can use private address block for floating IPs.
> * When creating new Node, it adds the floating address to NodeMetadata 
> publicAddresses set (IMO correctly) - in {{AllocateAndAddFloatingIpToNode}} 
> class.
> * when user refreshes the NodeMetadata by calling 
> {{computeService.getNodeMetadata(id)}}, the floating address is added to 
> private addresses (in {{ServerInRegionToNodeMetadata}} class). 
> Possible solution:
> The address returned from Openstack can also have a type:
> {code}
> {
> ...
> "addresses": {"qe-jenkins": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", 
> "version": 4, "addr": "172.16.130.24", "OS-EXT-IPS:type": "fixed"}, 
> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", "version": 4, "addr": 
> "10.8.54.75", "OS-EXT-IPS:type": "floating"}]}
> ...
> }
> {code}
> If the type present, then the {{ServerInRegionToNodeMetadata}} should use the 
> type. Otherwise, fallback to the current behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jclouds] [JCLOUDS-1079] Make Floating IPs public in the NodeMetadata in openstack-nova provider (#921)

[Josef Cacek]

Floating IPs from private address blocks were not available as public address 
after refreshing NodeMetadata.
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/921

-- Commit Summary --

  * [JCLOUDS-1079] Make Floating IPs public in the NodeMetadata in 
openstack-nova provider

-- File Changes --

M 
apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/functions/ServerInRegionToNodeMetadata.java
 (6)
M 
apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/domain/Address.java
 (51)
M 
apis/openstack-nova/src/test/java/org/jclouds/openstack/nova/v2_0/compute/functions/ServerInRegionToNodeMetadataTest.java
 (25)
M 
apis/openstack-nova/src/test/java/org/jclouds/openstack/nova/v2_0/parse/ParseServerDetailsStatesTest.java
 (12)
A 
apis/openstack-nova/src/test/java/org/jclouds/openstack/nova/v2_0/parse/ParseServerWithAddressExtensionsTest.java
 (107)
A 
apis/openstack-nova/src/test/resources/server_details_with_address_ext.json (77)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/921.patch
https://github.com/jclouds/jclouds/pull/921.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/921

Re: [jclouds-labs] JCLOUDS-1076: Initial implementation of Keys API (#234)

[Christopher Dancy]

@nacx done!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185441164

Re: [jclouds] Fix testSupplierExpirationReloadsTheCache sometimes failing (#920)

[Zack Shoylev]

merged

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/920#issuecomment-185441445

Re: [jclouds-labs] JCLOUDS-1076: Initial implementation of Keys API (#234)

[Ignasi Barrera]

Yes :)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185433561

Re: [jclouds-labs] JCLOUDS-1076: Initial implementation of Keys API (#234)

[Christopher Dancy]

@nacx squash-and-rebase and we can call it done then?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185431888

Re: [jclouds-labs] JCLOUDS-1076: Initial implementation of Keys API (#234)

[Ignasi Barrera]

lgtm now. Thanks @cdancy!
I'm sorry, I don't know a way to configure that. You'll have to play a bit with 
TestNG and the configurations. If you get stuck then ping me and I'll try to 
give a hand.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/234#issuecomment-185430293

[jclouds] Fix testSupplierExpirationReloadsTheCache sometimes failing (#920)

[Zack Shoylev]

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/920

-- Commit Summary --

  * Fix testSupplierExpirationReloadsTheCache sometimes failing

-- File Changes --

M 
compute/src/test/java/org/jclouds/compute/suppliers/ImageCacheSupplierTest.java 
(4)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/920.patch
https://github.com/jclouds/jclouds/pull/920.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/920

[jclouds-labs] Refactored ProfitBricks locations to not rely on existing DataCenters (#235)

[Ignasi Barrera]

This change removes the `DataCenter - Location` mapping. The current version 
uses the DataCenter entity to represent locations where nodes can be deployed, 
but that requires that a DataCenters for each location already exist in order 
to let users deploy servers to those locations, which is kind of annoying when 
you're getting started with a clean account.

The current PR changes this, and preconfigures the ProfitBricks regions and 
zones as jclouds properties (like AWS, rackspace and many others) and does not 
use a ProfitBricks specific entity to represent a Location. When provisioning 
nodes, jclouds will take care of creating the DataCenters if needed.

This has some benefits:

* Works out of the box without users having to pre-create anything to let 
jclouds work.
* Users can use the real location ids ("us/las", "de/fra", etc) when specifying 
the `locationId` in the template builder.
* There is no need for a custom implementation of the template builder that 
resolves the zones.
* Removes the need for the Location and DataCenter transformation functions.
* Allows users to override the properties to "restrict" the regions/zones 
jclouds can work with.
* Cleans up the ComputeService live tests so they don't need to precreate 
DataCenters. (Note that you might need to specify the `locationId` in the 
template property when running the live tests if the image being used exists 
only in one zone).

I haven't been able to run the complete ComputeService live test suite because 
provisioning was terribly slow. However, I've been able to properly list 
locations, images, and create nodes using the jclouds-cli compiled with the 
changes in this PR.

@devcsrj Could you please have a look at this, and give feedback about this 
functional change?

I think this location abstraction change makes a lot of sense and I'd pretty 
much like to have it merged before promoting the provider.
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds-labs/pull/235

-- Commit Summary --

  * Refactored locations to not rely on existing DataCenters

-- File Changes --

M profitbricks/README.md (4)
M 
profitbricks/src/main/java/org/jclouds/profitbricks/ProfitBricksProviderMetadata.java
 (20)
M 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/ProfitBricksComputeServiceAdapter.java
 (52)
D 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/ProfitBricksTemplateBuilderImpl.java
 (101)
M 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/config/ProfitBricksComputeServiceContextModule.java
 (34)
D 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/function/DataCenterToLocation.java
 (54)
D 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/function/LocationToLocation.java
 (47)
M 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/function/ProvisionableToImage.java
 (29)
M 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/function/ServerToNodeMetadata.java
 (42)
A 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/strategy/AssignDataCenterToTemplate.java
 (110)
A 
profitbricks/src/main/java/org/jclouds/profitbricks/compute/strategy/TemplateWithDataCenter.java
 (107)
M 
profitbricks/src/test/java/org/jclouds/profitbricks/compute/ProfitBricksComputeServiceLiveTest.java
 (77)
D 
profitbricks/src/test/java/org/jclouds/profitbricks/compute/function/DataCenterToLocationTest.java
 (77)
D 
profitbricks/src/test/java/org/jclouds/profitbricks/compute/function/LocationToLocationTest.java
 (62)
M 
profitbricks/src/test/java/org/jclouds/profitbricks/compute/function/ProvisionableToImageTest.java
 (52)
M 
profitbricks/src/test/java/org/jclouds/profitbricks/compute/function/ServerToNodeMetadataTest.java
 (68)

-- Patch Links --

https://github.com/jclouds/jclouds-labs/pull/235.patch
https://github.com/jclouds/jclouds-labs/pull/235.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/235

Jenkins build is back to normal : jclouds-labs-google #851

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-labs-google » jclouds Google Cloud Storage provider #851

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-guava-guice-compat » 18.0,3.0,OpenJDK 7 (latest) #106

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-guava-guice-compat » 18.0,4.0,OpenJDK 7 (latest) #106

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-guava-guice-compat » 19.0-rc1,4.0,OpenJDK 7 (latest) #106

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-guava-guice-compat » 17.0,4.0,OpenJDK 7 (latest) #106

[jenkins-no-reply]

See 

Jenkins build is back to normal : jclouds-guava-guice-compat » 19.0-rc1,3.0,OpenJDK 7 (latest) #106

[jenkins-no-reply]

See 

[jira] [Updated] (JCLOUDS-1079) Floating IPs should be public in openstack-nova provider

[Ignasi Barrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignasi Barrera updated JCLOUDS-1079:

Labels: openstack-nova  (was: )

> Floating IPs should be public in openstack-nova provider
> 
>
> Key: JCLOUDS-1079
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1079
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-compute
>Affects Versions: 2.0.0
>Reporter: Josef Cacek
>  Labels: openstack-nova
>
> Floating IPs from private address blocks are not presented as public address 
> of a NodeMetadata after refreshing it. (They are only configured as public 
> addresses when creating a new Node).
> * The OpenStack can use private address block for floating IPs.
> * When creating new Node, it adds the floating address to NodeMetadata 
> publicAddresses set (IMO correctly) - in {{AllocateAndAddFloatingIpToNode}} 
> class.
> * when user refreshes the NodeMetadata by calling 
> {{computeService.getNodeMetadata(id)}}, the floating address is added to 
> private addresses (in {{ServerInRegionToNodeMetadata}} class). 
> Possible solution:
> The address returned from Openstack can also have a type:
> {code}
> {
> ...
> "addresses": {"qe-jenkins": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", 
> "version": 4, "addr": "172.16.130.24", "OS-EXT-IPS:type": "fixed"}, 
> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", "version": 4, "addr": 
> "10.8.54.75", "OS-EXT-IPS:type": "floating"}]}
> ...
> }
> {code}
> If the type present, then the {{ServerInRegionToNodeMetadata}} should use the 
> type. Otherwise, fallback to the current behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCLOUDS-1079) Floating IPs should be public in openstack-nova provider

[Josef Cacek (JIRA)]

Josef Cacek created JCLOUDS-1079:


 Summary: Floating IPs should be public in openstack-nova provider
 Key: JCLOUDS-1079
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1079
 Project: jclouds
  Issue Type: Bug
  Components: jclouds-compute
Affects Versions: 2.0.0
Reporter: Josef Cacek


Floating IPs from private address blocks are not presented as public address of 
a NodeMetadata after refreshing it. (They are only configured as public 
addresses when creating a new Node).

* The OpenStack can use private address block for floating IPs.
* When creating new Node, it adds the floating address to NodeMetadata 
publicAddresses set (IMO correctly) - in {{AllocateAndAddFloatingIpToNode}} 
class.
* when user refreshes the NodeMetadata by calling 
{{computeService.getNodeMetadata(id)}}, the floating address is added to 
private addresses (in {{ServerInRegionToNodeMetadata}} class). 

Possible solution:
The address returned from Openstack can also have a type:
{code}
{
...
"addresses": {"qe-jenkins": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", 
"version": 4, "addr": "172.16.130.24", "OS-EXT-IPS:type": "fixed"}, 
{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:bf:82:43", "version": 4, "addr": 
"10.8.54.75", "OS-EXT-IPS:type": "floating"}]}
...
}
{code}
If the type present, then the {{ServerInRegionToNodeMetadata}} should use the 
type. Otherwise, fallback to the current behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCLOUDS-1078) Implement the ImageExtension in ProfitBricks

[Ignasi Barrera (JIRA)]

Ignasi Barrera created JCLOUDS-1078:
---

 Summary: Implement the ImageExtension in ProfitBricks
 Key: JCLOUDS-1078
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1078
 Project: jclouds
  Issue Type: Improvement
  Components: jclouds-compute
Affects Versions: 1.9.2
Reporter: Ignasi Barrera
Assignee: Reijhanniel Jearl Campos


ProfitBricks supports creating snapshots of existing servers and use them as 
images to provision new nodes, so the ImageExtension of the compute service 
abstraction should be implemented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)