jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <andrea.tu...@gmail.com>
Subject Re: Question about GCE Provider
Date Wed, 22 Apr 2015 07:53:18 GMT
Daniel,

+1 I'd like to see that fixed as well as soon as possible. Let's open a
JIRA ticket for this and try to coordinate there.

I don't have enough bandwidth these days so please go ahead with the
implementation. Obviously, I'm more than happy to help you (code review,
test, discussions)

Thanks,
Andrea


On Wed, Apr 22, 2015 at 5:54 AM Daniel Broudy <broudy@google.com> wrote:

> I would like to move forward on this change if there are no objections. I
> will open a JIRA issue to track it.
>
> Andrea are you working on updating how firewalls are created? It would be
> good to coordinate to avoid conflicts.
>
> On Tue, Apr 21, 2015 at 11:02 AM, Daniel Broudy <broudy@google.com> wrote:
>
> > I thing targetTags are exactly the way to go in this case.
> >
> > On Mon, Apr 20, 2015 at 1:30 PM, Andrea Turli <andrea.turli@gmail.com>
> > wrote:
> >
> >> Daniel,
> >>
> >> I agree that network-per-group idea doesn't scale very well, but there
> are
> >> some advantages that we can lose if we have just one single network.
> >> having a single network sounds like a problem when you want to attach a
> >> particular firewall rule only to a VM. Say that a network "jclouds"
> >> already
> >> exists and defines a firewall rule for 22 and 80. Every VM attached to
> >> that
> >> network will have those port opened even if it is not strictly required.
> >> Do
> >> you think targetTags are then what we want to use to specify which
> >> instance
> >> can accept that traffic on that port?
> >>
> >> Thanks,
> >> Andrea
> >>
> >> On Wed, Apr 15, 2015 at 11:01 PM Daniel Broudy <broudy@google.com>
> wrote:
> >>
> >> > There are some pretty strict quotas on the rate at which you can
> create
> >> and
> >> > destroy networks. I think the current network-per-group idea doesn't
> >> scale
> >> > well.
> >> >
> >> >
> >> > "A network performs the same function that a router does in a home
> >> network:
> >> > it describes the network range and gateway IP address, handles
> >> > communication between instances, and serves as a gateway between
> >> instances
> >> > and callers outside the network. [...] Any communication between
> >> instances
> >> > in different networks, even within the same project, must be through
> >> > external IP addresses." [1]
> >> >
> >> > I think we should switch to using the default network and only
> creating
> >> a
> >> > new network if the user specifies that is what they want.
> >> >
> >> > [1] https://cloud.google.com/compute/docs/networking#networks_1
> >> >
> >> > On Tue, Apr 14, 2015 at 10:21 PM, Andrea Turli <
> andrea.turli@gmail.com>
> >> > wrote:
> >> >
> >> > > Daniel,
> >> > >
> >> > > Is it a common use case to spin up more than 5 node groups on one
> >> > project?
> >> > > >
> >> > >
> >> > > I think in jclouds we should support the most generic case possible,
> >> not
> >> > > only 5 node groups then.
> >> > >
> >> > > >
> >> > > > If it is, we should not be creating one network per node group
on
> >> GCE
> >> > > > because there is quota of 5 networks per project.
> >> > > >
> >> > > > I am wondering why we create a new network for each group. Would
> it
> >> > make
> >> > > > more sense to use the default network for all groups and keep
> groups
> >> > > > distinct by using tags and naming conventions?
> >> > > >
> >> > >
> >> > > I think a network per node group makes sense for traffic
> segmentation
> >> and
> >> > > multi tenancy but if you think it shouldn't be necessary I think it
> is
> >> > good
> >> > > to have your feedback here as you are the expert :)
> >> > > Maybe we could keep going with this approach and make sure that the
> >> > network
> >> > > (and the firewall rules!) gets deleted when the node group is
> >> destroyed.
> >> > >
> >> > > I am still gaining familiarity with the compute abstraction.
> >> > > >
> >> > >
> >> > > Best,
> >> > > Andrea
> >> > >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message