Re: CloudStack and projects

[Richard Downer <ri...@cloudsoftcorp.com>]

Hi Andrew, Hugo,

Apologies for bumping a rather old thread :-)

We're looking at a project that needs projects (so to speak) and
wondered if anything happened on this subject? I'm seeing no activity
on the JCLOUDS-252 ticket or on a quick list search so I guess not.

I should be able to offer some time to get this resolved. My first
thought is adding a property used at context creation time to set the
desired project ID; then all project-aware operations in the compute
service will use this project ID.

I did notice that it's possible to set the projectid in
DeployVirtualMachineOptions, but once I tried this out by hacking in
an ID, the VM did start in the correct project. However follow-up
operations like runScriptOnNode failed - it kept using
'listVirtualMachines' to try and find the VM but did not pass the
project ID in the query, so the CloudStack never returned the VM in
its response, until jclouds gave up and thought that the VM was dead.
This makes me think that it may be better to have the project ID as a
context-wide parameter, and any time the compute service calls a
project-aware operation, it fills in the project ID. Security groups
are an example of something else that lives in project namespaces. Is
this a good route?

On 23 August 2013 01:18, Andrew Bayer <an...@gmail.com> wrote:
> Yeah, the gist is to do something like how listNodes() works with
> regions/zones/whatever on EC2 or Nova - treating projects as if they were
> another form of Location, I think.
>
> A.
>
>
> On Thu, Aug 22, 2013 at 6:48 PM, Hugo Trippaers <tr...@gmail.com> wrote:
>
>> Hey Andrew,
>>
>> I'm also willing to dive into it and get it done. If you can share your
>> ideas, I'd be happy to get going. Good chance to get some experience with
>> jclouds internals :-)
>>
>> The ticket is jclouds-252.
>>
>> Cheers,
>>
>> Hugo
>>
>> Sent from my iPhone
>>
>> On 22 aug. 2013, at 19:45, Andrew Bayer <an...@gmail.com> wrote:
>>
>> > Yeah, this is something I need to tackle. Hugo, could you open a JIRA for
>> > this? I have some ideas and will make a run at it in the next week or
>> two...
>> >
>> > A.
>> >
>> >
>> > On Thu, Aug 22, 2013 at 9:43 AM, Andrew Phillips <aphillips@qrmedia.com
>> >wrote:
>> >
>> >> I suspect abayer may be the most suitable person to assist here... ;-)
>> >>
>> >> ap
>> >>
>>



-- 
Richard Downer • Principal Engineer • Cloudsoft Corporation •
http://www.cloudsoftcorp.com
GitHub richardcloudsoft • Twitter @FrontierTown

Re: CloudStack and projects

[Andrew Phillips <ap...@qrmedia.com>]

> This makes me think that it may be better to have the project ID as a
> context-wide parameter, and any time the compute service calls a
> project-aware operation, it fills in the project ID. Security groups
> are an example of something else that lives in project namespaces. Is
> this a good route?

Would it make sense to approach this in the same way as region-scoped  
blobstores [1, 2]? This would mean having something like a  
ProjectScopedComputeServiceContext extends ComputeServiceContext.

One question would be: how many different APIs/providers require this?

ap

[1] https://issues.apache.org/jira/browse/JCLOUDS-299
[2]  
https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/blobstore/RegionScopedBlobStoreContext.java