Apologies for the late reply.
I think we could go for both approaches. The current compute interface
now would support getting a Network scoped location, as long as the
TempalteBuilder can resolve its region to select the image/hardware.
But let's go for your suggested approach and ask users to be
I think the answers to the questions below follow from the answer to another
question. Do we support provisioning machines to network scoped location? If
yes, then "listAvailableLocations" should follow suit and list the networks as
well. When a non-network location is set it's auto-scoped to th
Using the Location parameter to create a security group in a Network
might do the trick, and perhaps we find the way to document or model
it so it is easy to write portable code. We just need to think a bit
more about it and explore all the implications and possible
alternatives.
Here are some add
Ok Svet;
It would certainly be a shame to have to write
if (provider.equals("GCE")) {
createSecurityGroupOneWay();
} else {
createSecurityGroupAnotherWay();
}
I guess I agree it's probably better, when the provider doesn't support a
concept, to avoid having an implementation that's
> if that entity does not exist in GCE and
> users won't be able to use the extension as in other clouds, is there
> a real use case for it that justifies its implementation?
My personal drive for the implementation is to reuse existing code managing the
ingress access to (freshly spun up) nodes
I agree it is a grey area where we can only do our best.
I'd say it is ok to skip egress rules and to only consider the rules
created by jclouds, that is something we could assume given the fact
that the concept of security groups does not exist in GCE, which
brings me to the question: if that ent
The onboarding experience takes a best effort approach and never represents the
cloud state exactly. It's a gray area of compromises.
For example GCE supports ingress/egress; allow/deny rules. Of those only
ingress+allow rules can be represented using IpPermission. What do we do about
the rest?
hi Ignasi,
that's an interesting issue. Re. your last paragraph, that could certainly
be a good approach, but it still won't address the question of onboarding
existing infrastructure, right? i.e. where there are rules that weren't
written according to those conventions - or of upgrading to the
I understand the motivation behind ignoring existing stuff, but I have
some concerns.
Onboarding existing cloud infrastructure is a valid use case for
jclouds users, and that can already be done (limited by the bounds of
the Compute abstraction) with the current jclouds implementation. It
is fair
> Svet you don't mention GCE "tags" or the question of subnets in the above:
That's right, tags are an important part of the convention and I didn't expand
on that. Your description nicely captures the idea.
I believe the security groups will work across subnets in a single vpc network.
Svet.
I like the sound of this proposal, I think it's certainly worth
investigating.
Ignasi those are good questions you've asked. Here's my thoughts:
We can regard 'security groups' on GCE as a jclouds "overlay", and be
explicit about that in documentation. What I mean here is that we don't
need to d
I think the best thing we can do for the extension is to focus on jclouds
managed resources and ignore the rest.
This means that jclouds will know how to map from firewall rules to
SecurityGroups and back, and be able to figure out a security group is applied
on a node.
This will allow users to
Thanks for starting this discussion Svet!
It would be great to come up with a solution we are happy with.
The main issue I see here is that the primary entity of the extension,
the SecurityGroup, does not have a mapping in GCE (which was one of
the reasons we decided to remove the old implementat
13 matches
Mail list logo
