[
https://issues.apache.org/jira/browse/JCLOUDS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kavan K Patil updated JCLOUDS-238:
----------------------------------
Description:
I have been testing NovaApi against HP Cloud and have been working with both
per AZ endpoint model and a region wide endpoint model in different regions.
For clarity I would define the following two terms so that it helps me
providing further details:
Per AZ endpoint model : I call it so as we get a per AZ compute endpoint url.
Using this URL we could only work with a particular AZ of a cloud provider
(e.g. HP Cloud region-a has az1.region-a.geo-1 as one AZ and has its own
compute endpoint)
Region wide endpoint model: In this model there will be one compute endpoint
exposed by the provider. But underneath there could be multiple AZs. All the
openstack services work region wide and compute instances can be placed on all
AZs within the region selectively through an option while creating instances.
(e.g. HPCloud region-b.geo-1, which will have a single endpoint for compute for
the entire region. This is still in private beta stage.)
The existing framework with JClouds doesn't seem to fit the region wide model
and below I describe 3 issues I see.
To start with I can create a single connection for HP Cloud as below
{code}
-----------
NovaApi api =
ContextBuilder.newBuilder("hpcloud-compute")
.credentials(identity, password)
.modules(modules)
.apiVersion("2") //The api version of region-b.geo-1 is 2
which is required for next steps
-------------
{code}
And the issues:
1. But to get a reference to the ServerApi under this region I need to give the
name of a region, though the method name clearly expects a zone id.
{code}
-------------
//So now we have a new connection to region-b-geo-1
//But to get a ServerApi handle I need to do
//This looks ugly, as i need to provide the name of region for a zone!
serverApi = this.novaApi.getServerApiForZone("region-b.geo-1");
//Ideally one should be able to do this instead of the above. But JClouds
throws an error that an endpoint for this AZ was not found
//serverApi = this.novaApi.getServerApiForZone("az1");
------------------------------
{code}
2. Also now that I have a ServerApi to the region, I don't get to select an AZ
to schedule an instance to a specific one. There is option under
CreateServerOptions to specify an AZ name!
3. And the below call should return all AZs (az1, az2, az3), but it only
returns region-b.geo-1
{code}
---------------------
this.novaApi.getConfiguredZones()
---------------------
{code}
I think this is due to the fact that the implementation of getConfiguredZones()
is mapped to the endpoints in the service catalogue rather than the below API
extension:
{code}
----------------
curl -i
https://region-b.geo-1.compute.hpcloudsvc.com/v2/<tenant-id>/os-availability-zone
-X GET -H "Accept: application/json" -H "X-Auth-Token: <token>"
RESP: [200] CaseInsensitiveDict({'date': 'Mon, 05 Aug 2013 10:35:03 GMT',
'content-length': '236', 'content-type': 'application/json',
'x-compute-request-id': 'req-c19dcfba-8a21-4a7e-b463-19943267c9bb'})
RESP BODY: {"availabilityZoneInfo": [{"zoneState": {"available": true},
"hosts": null, "zoneName": "az1"}, {"zoneState": {"available": true}, "hosts":
null, "zoneName": "az2"}, {"zoneState": {"available": true}, "hosts": null,
"zoneName": "az3"}]}
--------------
{code}
was:
I have been testing NovaApi against HP Cloud and have been working with both
per AZ endpoint model and a region wide endpoint model in different regions.
For clarity I would define the following two terms so that it helps me
providing further details:
Per AZ endpoint model : I call it so as we get a per AZ compute endpoint url.
Using this URL we could only work with a particular AZ of a cloud provider
(e.g. HP Cloud region-a has az1.region-a.geo-1 as one AZ and has its own
compute endpoint)
Region wide endpoint model: In this model there will be one compute endpoint
exposed by the provider. But underneath there could be multiple AZs. All the
openstack services work region wide and compute instances can be placed on all
AZs within the region selectively through an option while creating instances.
(e.g. HPCloud region-b.geo-1, which will have a single endpoint for compute for
the entire region. This is still in private beta stage.)
The existing framework with JClouds doesn't seem to fit the region wide model
and below I describe 3 issues I see.
So start with I can create a single connection for HP Cloud as below
{code}
-----------
NovaApi api =
ContextBuilder.newBuilder("hpcloud-compute")
.credentials(identity, password)
.modules(modules)
.apiVersion("2") //The api version of region-b.geo-1 is 2
which is required for next steps
-------------
{code}
1. But to get a Handle to the ServerApi under this region I need to give the
name of a region!
{code}
-------------
//So now we have a new connection to region-b-geo-1
//But to get a ServerApi handle I need to do
//This looks ugly, as i need to provide the name of region for a zone!
serverApi = this.novaApi.getServerApiForZone("region-b.geo-1");
//As the below throws error that an endpoint for this AZ was not found
//serverApi = this.novaApi.getServerApiForZone("az1");
------------------------------
{code}
2. Also now that I have a ServerApi to the region, I don't get to select the an
AZ to place a instance as there is no CreateServerOptions to specify an AZ name!
3. And the below call should return all AZs (az1, az2, az3), but it only
returns region-b.geo-1
{code}
---------------------
this.novaApi.getConfiguredZones()
---------------------
{code}
I think this is due to the fact that the implementation of getConfiguredZones()
is mapped to the endpoints in the service catalogue rather than the below API
extension:
{code}
----------------
curl -i
https://region-b.geo-1.compute.hpcloudsvc.com/v2/<tenant-id>/os-availability-zone
-X GET -H "Accept: application/json" -H "X-Auth-Token: <token>"
RESP: [200] CaseInsensitiveDict({'date': 'Mon, 05 Aug 2013 10:35:03 GMT',
'content-length': '236', 'content-type': 'application/json',
'x-compute-request-id': 'req-c19dcfba-8a21-4a7e-b463-19943267c9bb'})
RESP BODY: {"availabilityZoneInfo": [{"zoneState": {"available": true},
"hosts": null, "zoneName": "az1"}, {"zoneState": {"available": true}, "hosts":
null, "zoneName": "az2"}, {"zoneState": {"available": true}, "hosts": null,
"zoneName": "az3"}]}
--------------
{code}
> api/openstack-compute supports only a per AZ deployment model
> -------------------------------------------------------------
>
> Key: JCLOUDS-238
> URL: https://issues.apache.org/jira/browse/JCLOUDS-238
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
> Affects Versions: 1.6.0
> Reporter: Kavan K Patil
>
> I have been testing NovaApi against HP Cloud and have been working with both
> per AZ endpoint model and a region wide endpoint model in different regions.
> For clarity I would define the following two terms so that it helps me
> providing further details:
> Per AZ endpoint model : I call it so as we get a per AZ compute endpoint url.
> Using this URL we could only work with a particular AZ of a cloud provider
> (e.g. HP Cloud region-a has az1.region-a.geo-1 as one AZ and has its own
> compute endpoint)
> Region wide endpoint model: In this model there will be one compute endpoint
> exposed by the provider. But underneath there could be multiple AZs. All the
> openstack services work region wide and compute instances can be placed on
> all AZs within the region selectively through an option while creating
> instances. (e.g. HPCloud region-b.geo-1, which will have a single endpoint
> for compute for the entire region. This is still in private beta stage.)
> The existing framework with JClouds doesn't seem to fit the region wide model
> and below I describe 3 issues I see.
> To start with I can create a single connection for HP Cloud as below
> {code}
> -----------
> NovaApi api =
> ContextBuilder.newBuilder("hpcloud-compute")
> .credentials(identity, password)
> .modules(modules)
> .apiVersion("2") //The api version of region-b.geo-1 is 2
> which is required for next steps
> -------------
> {code}
> And the issues:
> 1. But to get a reference to the ServerApi under this region I need to give
> the name of a region, though the method name clearly expects a zone id.
> {code}
> -------------
> //So now we have a new connection to region-b-geo-1
> //But to get a ServerApi handle I need to do
> //This looks ugly, as i need to provide the name of region for a zone!
> serverApi = this.novaApi.getServerApiForZone("region-b.geo-1");
> //Ideally one should be able to do this instead of the above. But JClouds
> throws an error that an endpoint for this AZ was not found
> //serverApi = this.novaApi.getServerApiForZone("az1");
> ------------------------------
> {code}
> 2. Also now that I have a ServerApi to the region, I don't get to select an
> AZ to schedule an instance to a specific one. There is option under
> CreateServerOptions to specify an AZ name!
> 3. And the below call should return all AZs (az1, az2, az3), but it only
> returns region-b.geo-1
> {code}
> ---------------------
> this.novaApi.getConfiguredZones()
> ---------------------
> {code}
> I think this is due to the fact that the implementation of
> getConfiguredZones() is mapped to the endpoints in the service catalogue
> rather than the below API extension:
> {code}
> ----------------
> curl -i
> https://region-b.geo-1.compute.hpcloudsvc.com/v2/<tenant-id>/os-availability-zone
> -X GET -H "Accept: application/json" -H "X-Auth-Token: <token>"
> RESP: [200] CaseInsensitiveDict({'date': 'Mon, 05 Aug 2013 10:35:03 GMT',
> 'content-length': '236', 'content-type': 'application/json',
> 'x-compute-request-id': 'req-c19dcfba-8a21-4a7e-b463-19943267c9bb'})
> RESP BODY: {"availabilityZoneInfo": [{"zoneState": {"available": true},
> "hosts": null, "zoneName": "az1"}, {"zoneState": {"available": true},
> "hosts": null, "zoneName": "az2"}, {"zoneState": {"available": true},
> "hosts": null, "zoneName": "az3"}]}
> --------------
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
