Re: [vdsm] Future of Vdsm network configuration

[Dan Kenigsberg]

On Wed, Nov 14, 2012 at 10:54:34AM -0500, Saggi Mizrahi wrote:
 I'm late to the party as usual...
 
 I'm all for dynamic set up of hosts, I think it's the only way to go. I don't 
 understand how it can work anyway else.

I did not expect the thread to go this way, but I agree that network
setup is an exception: for storage and virtual machines, we do not
persist anything on the node.

For networking we need to persist only the management connection.
Everything else can be volatile, created by the client after the node
boots.

 
 That being said, if everything is set up dynamically it doesn't matter what 
 backend we use to set it up as long as we can query the state.
 We can even mix and match. Or am I missing something.

Choosing a backend is important, as all implementations are. We have the
setupNetwork API. We could change its semantics to mean do not
persist. Now is the time to consider implementations, too.

Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration

[Itamar Heim]

On 11/17/2012 11:56 AM, Gary Kotton wrote:

On 11/17/2012 11:00 AM, Alon Bar-Lev wrote:

Hello,

After discussion calm down, I want to once again to ask a question.

Why isn't this discussion focusing on the interface vdsm will use to
access network provider? Why should vdsm core care which network
technology it actually uses?


Quantum?


1. that's still a specific implementation.
2. last i checked, it is far from covering the API needed by vdsm for 
provisioning network configurations, rather than just consuming them?
(i.e., i don't remember quantum ever intends to provide an api to bond 
physical interfaces, etc).






With proper design of such interface, and the ability to select
interface implementation using configuration, vdsm will be able to
work with various of technologies without a change.

Technologies can be either network manager, ovs, libvirt or basic.
What popular now can be unpopular in future, what is considered stable
enough for now, may be not stable enough for future uses, what is
maintained now may be unmaintained in future.

Developing tightly coupled software is something I would avoid if not
absolutely required.

People may vote which interface they like to have now and we can
implement one, while in time we may see other implementations as
contributions. This will also allow us to move from one technology to
another with decent effort/costs if required for any reason.

Best Regards,
Alon Bar-Lev.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel