Currently agent is in next face of his life. There are some work in progress to change that code. Because of that it’s right timing to discuss about that and find some proper way how to work with this. The biggest issue with Octavia is that there is almost no documentation about what everything to be able to use this project. There is laconic doc about creating new images so always everyone is able to build his own image. Were not blocking that behavior.
Lubosz Kosnik Cloud Software Engineer OSIC lubosz.kos...@intel.com > On Jun 30, 2016, at 8:01 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > >> On 30 Jun 2016, at 06:03, Kosnik, Lubosz <lubosz.kos...@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. > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev