[Deepsea-users] stage 1: network discovery

[Ricardo Dias]

On 2016-12-12 11:26:13, Eric Jackson wrote:
> On Monday, December 12, 2016 03:50:15 PM Ricardo Dias wrote:
> > On 2016-12-12 10:28:10, Eric Jackson wrote:
> > 
> > I'm using a cluster created in OVH cloud provider. Every node has a
> > different IP address, but have a netmask of /32. The IP addresses are
> > public and the access rules are controlled by the security group of
> > the instances.
> 
> I haven't tried OVH.
> > 
> > 
> > I think we can assume that all networks (in this case there is a network
> > for each node) are public. And by reading the "Network Configuration"
> 
> Maybe in this instance, but if I have 4 network interfaces on a host, why 
> would I assume that all are public?  In the comments of the code, I wrote that 
> this is a best guess but it seems to be reasonable so far.
> 
> > section [1] in Ceph documentation, we can specify several public
> > networks. This means we just need to extend a bit the code to deal with
> > a list of public networks instead of only one.
> > 
> > The rule for network detection should be:
> > Given a set of networks NTS:
> >  1) if each network in NTS only contains one node, then we consider all
> >     networks public
> >  2) otherwise we fallback to the current logic, which is:
> >     pick the network with more nodes as the public network, and the
> >     second with more nodes as the cluster network.
> 
> I think I would prefer reversing the behavior.   That is, if nothing can be 
> deduced, then check if all nodes have a single network and apply the list to 
> both the cluster and public networks.

I agree.

> 
> If I have several hosts with two networks, but a few of the hosts are 
> experiencing an issue with one network, I would prefer the current behavior.  
> Stage 1 would write the configuration and the validation would fail that some 
> nodes do not seem to have a cluster network.  (I think it would be hard for 
> Salt to work without a public network, but I'm sure there's a way.)
> 
> If I follow the above, the entire cluster will be deployed and the admin will 
> learn that all nodes are configured to use a single network.  While there is a 
> few ways out of that scenario, I do not want to put them into it initially.

I don't understand what you said above. Is this a justification to
reverse the order that I proposed? If it is, I agree :)

> 
> > 
> > > > - Why is DS storing the "public_network" and "cluster_network" in
> > > > 
> > > >   "pillar/ceph/stack/default/ceph/cluster.yml"? What are their purposes?
> > > >   Do we really need them?
> > > 
> > > Take a look at /srv/salt/ceph/configuration/files/ceph.conf.j2.  The
> > > public and cluster networks are specified there.
> > 
> > As I said in the comment above, we can add a list of public networks in
> > the "public_network" config option.
> 
> You asked why the variables are defined in the pillar.  So, that this Jinja 
> template can use them is my answer.

I understood what you meant. My comment was just a followup of my
comment above.

> 
> Converting the public_network/cluster_network to lists is not difficult, but 
> thinking about the upgrade to SES5 needs to be thought about too.

I don't understand what converting public_network to lists has to do
with upgrading to SES5. Can you clarify?

> > 
> > 
> > [1] http://docs.ceph.com/docs/jewel/rados/configuration/network-config-ref/