Open Stack

> On Jun 30, 2016, at 7:01 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> 
> 
>> On 30 Jun 2016, at 06:03, Kosnik, Lubosz <lubosz.kosnik at intel.com> wrote:
>> 
>> Like Doug said Amphora suppose to be a black box. It suppose to get some data - like info in /etc/defaults and do everything inside on its own.
>> Everyone will be able to prepare his own implementation of this image without mixing things between each other.
> 
> That would be correct if the image would not be maintained by the project itself. Then indeed every vendor would prepare their own image, maybe collaborate on common code for that. Since this code is currently in octavia, we kinda need to plug into it for other vendors. Otherwise you pick one and give it a preference.

No, I disagree with that premise, because it pre-supposes that we have any interest in supporting *this exact reference implementation* for any period of time.

Octavia has a few goals:

- Present an openstack loadbalancing API to operators and users.
- Put VIPs on openstack clouds, that do loadbalancy things, and are always there and working.
- Upgrade seamlessly.

That’s it. A few more constraints:

- It’s an openstack project, so it must be python, with our supported version, running on our supported OSs, using our shared libraries, being open, level playing field, etc…

Nowhere in there is the amp concept, or that we must always require nova, or that said amps must run a REST agent, or anything about the load-balancing backend.The amp itself, and all the code written for it, is just a means to an end. If the day comes tomorrow that the amp agent and amp concept is silly, as long as we have a seamless upgrade and those VIPs keep operating, we are under no obligation as a project to keep using that amp code or maintaining it. Our obligation is to the operators and users.

The amp “agent” code has already gone through two iterations (direct ssh, now a silly rest agent on the amp). We’ve already discussed that the current ubuntu based amp is too heavy-weight and needs to change. Tomorrow it could be based on a microlinux. And the day after that, cirros plus a static nginx. And the day after that, a docker swarm with an proxy running on a simulated minecraft redstone machine (well, we’d have to find an open-source clone of minecraft, first.)

The point being, as a project contributor, I have zero interest in signing up for long-term maintenance of something that 1) is not user visible, and 2) is likely to change; all for the sake of any particular vendors sensibilities. The current octavia will run just fine on ubuntu or redhat, and the current amp image will launch just fine on a nova run by either, too.

That said, every part of octavia is pluggable with drivers, and while I will personally resist adding multiple reference drivers in-tree, it doesn’t mean everyone will, nor does it preclude using shims and external repos.

That’s just my opinion, but I’d hate to see us tying our own hands by adding support and maintenance burden at this early stage, beyond delivering VIPs to users. I’d be more inclined to see the amp image itself cease to exist inside an openstack project, before I want to spend the time supporting lots of them, for non-technical reasons.

Thanks,
doug



> 
> But if we can make the agent itself vendor agnostic, so that the only differentiation would happen around components stuffed into the image (kernel, haproxy version, security tweaks, …), then it will be obviously a better path than trying to template the agent for multiple vendors.

> 
> A silly question: why does the agent even need to configure the network using distribution mechanisms and not just calling to ip link and friends?
> 
> Ihar
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev