stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sathyasuriya Priya <sathyasur...@gmail.com>
Subject Re: [gsoc] GCE support - important aspects
Date Fri, 08 Aug 2014 08:15:24 GMT
hi Nirmal,

I am facing some problems if I test with master branch. For example, not
able to configure autoscale policy, etc from stratos manager UI.
Not sure if there are known issues.

I moved my changes to 4.0.0 based and created a branch gce-4.0.0 [1], and
did some testing.
I also started document on testing different features [2].
Please suggest on further testing combinations.

I also have a script [3] (based on Chris's project [4]) to install
prerequisites, puppet server, compile & install stratos. It should be
pretty similar to other IaaS, except only one quirk. But helps to setup
things faster. I will include more info about this in the doc.

[1] https://github.com/suriyapriya/stratos/tree/gce-4.0.0
[2]
https://docs.google.com/document/d/1_UyglvcuNASxFbC6YK4zDoKohx9xiiqBNZqMiezkhzo/
[3] https://gist.github.com/suriyapriya/75fc471cd3aee0b810aa
[4] https://github.com/snowch/stratos-vagrant-box/

Thanks
Suriya


On Sat, Aug 2, 2014 at 11:55 PM, Sathyasuriya Priya <sathyasuriya@gmail.com>
wrote:

> Thanks Nirmal.
>
> I am moving the changes to latest codebase.
> I will send PR shortly after that.
>
>
> On Sat, Aug 2, 2014 at 9:48 PM, Nirmal Fernando <nirmal070125@gmail.com>
> wrote:
>
>> Hi Suriya,
>>
>> Please see my comments inline.
>>
>>
>> On Sun, Aug 3, 2014 at 4:33 AM, Sathyasuriya Priya <
>> sathyasuriya@gmail.com> wrote:
>>
>>> Hi Nirmal, devs,
>>>
>>> Following are some important aspects of GCE design/implementation.
>>> Let me know of any changes/suggestions.
>>>
>>> *1. GCE credential: *Jclouds uses GCE service accounts for
>>> communicating with IaaS. This includes a service account email address (for
>>> example,
>>> 607132743639-fihqilsm9pemf9c98ppmv1otbvtmgdij@developer.gserviceaccount.com)
>>> and a private key in text(~1000 chars). This identity, credential can be
>>> specified in cloud-controller.xml as follows. Currently mode 1 is
>>> implemented. Based on suggestions we can implement mode 2 or 3.
>>>
>>> *Mode 1:* private key in pem text.
>>>   <identity svns:secretAlias="cloud.controller.gce.identity">
>>>
>>> 607132743639-fihqilsm9pemf9c98ppmv1otbvtmgdij@developer.gserviceaccount.com
>>>   </identity>
>>>   <credential svns:secretAlias="cloud.controller.gce.credential">
>>> -----BEGIN PRIVATE KEY-----
>>> #### ~15 lines of private key
>>> -----END PRIVATE KEY-----
>>>   </credential>
>>>
>>> *Mode 2:* Instead of giving the private key in text format, we can give
>>> a path to a file. The file will have the key in pem format.
>>>   <identity svns:secretAlias="cloud.controller.gce.identity">
>>>
>>> 607132743639-fihqilsm9pemf9c98ppmv1otbvtmgdij@developer.gserviceaccount.com
>>>   </identity>
>>>   <credential svns:secretAlias="cloud.controller.gce.credential">
>>>   /home/suriya/key/privatekey.pem
>>>   </credential>
>>>
>>> *Mode 3:* Mixed mode 1 & 2. Either pem text or path to file can be
>>> there. Stratos code can try to autodetect the mode.
>>>
>>
>> Ok, GCE's account authentication mechanism is key based then. It's bit
>> different to other IaaS providers. Out of curiosity does GCE use another
>> key pair to spawn instances?
>>
>> I'd like to have Mode2, but for the first iteration, Mode1 is perfectly
>> fine.
>>
>>
>>> *2. Network*: GCE instance can connect to only one network [1]. I
>>> think, this is different from EC2 or openstack, where one instance can
>>> connect to many networks. So stratos server needs to be in same network as
>>> cartridge instances. I hope this is ok for multi-tenant mode in stratos.
>>> This network name can be mentioned in cartridge json as follows (similar to
>>> EC2, but only one name should be specified)
>>>       "networkInterfaces": [
>>>         {
>>>           "networkUuid": "default-network-name"
>>>         }
>>>       ]
>>>
>>>
>> Ya, there's no issue in multi-tenant mode. I hope this is not mandatory.
>>
>> Connecting only to one network, is certainly not a blocker IMO.
>>
>>  *3. Naming convention:* I have used 'gce' in all stratos code, and
>>> wherever needed in xml, etc. But in jclouds [2] 'google-compute-engine' is
>>> being used. So in the code copied from jclouds to stratos
>>> dependencies/jclouds/apis/google-compute-engine/, 'gce' is not used. I hope
>>> this is ok.
>>>
>>
>> Ya, this is ok.
>>
>> Looking forward to see a PR soon :)
>>
>> Great work so far!
>>
>>>
>>> [1] https://developers.google.com/compute/docs/instances-and-network
>>> [2] https://github.com/jclouds/jclouds-labs-google
>>> [3]
>>> https://github.com/suriyapriya/incubator-stratos/tree/gce/dependencies/jclouds/apis/google-compute-engine
>>>
>>> Thanks
>>> Suriya
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> Nirmal Fernando.
>> PPMC Member & Committer of Apache Stratos,
>> Senior Software Engineer, WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>

Mime
View raw message