Re: [openstack-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs
Hi Team, kuryr-libnetwork needs kuryr(along with refactoring changes) to be installed through requirements.txt, [1] . If we merge changes in kuryr to achieve so we might end-up messing up both repos. To handle this, I have forked kuryr repo on my github account, [2], and doing required changes in my local forked kuryr. kuryr-libnetwork patches will resolve kuryr dependency from my forked kuryr project(with required changes). Once kuryr-libnetwork is stable with all unit test-cases and functional test cases working as they do today in kuryr repo, we can start making changes to kuryr project. This way atleast one repo would be working at all time. I will keep updating patches in kuryr from my forked kuryr project. thoughts? Regards Vikas [1] https://review.openstack.org/#/c/336661/4/requirements.txt [2] https://github.com/vikaschoudhary16/kuryr/tree/rpc_ns On Tue, Jun 28, 2016 at 3:45 PM, Vikas Choudhary wrote: > > > On Tue, Jun 28, 2016 at 3:41 PM, Antoni Segura Puimedon < > toni+openstac...@midokura.com> wrote: > >> >> >> On Tue, Jun 28, 2016 at 11:54 AM, Vikas Choudhary < >> choudharyvika...@gmail.com> wrote: >> >>> >>> >>> On Tue, Jun 28, 2016 at 1:53 PM, Antoni Segura Puimedon < >>> toni+openstac...@midokura.com> wrote: >>> On Mon, Jun 27, 2016 at 11:10 AM, Vikas Choudhary < choudharyvika...@gmail.com> wrote: > > > On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq > wrote: > >> Vikas, >> >> Thanks for starting this. Where would you classify the Segmentation >> (VLANID etc) allocation engine. Currently, the libnetwork plugin is tied >> to >> the api and talks to Neutron, how would libnetwork and api part interact? >> >> As per my current understanding, it should be present be part of > Kuryr-controller(server) running on cluster master node. My proposal is to > move all neutron api calling part to kuryr-controller and let libnetwork > plugin make request to kuryr-controller. > Right now we have three repositories - kuryr - kuryr-libnetwork - kuryr-kubernetes My proposal is that the common code (as described below in Vikas' email, this includes the binding code) lives in `kuryr`. The kuryr server for the nested swarm case would also live there, as it would be a generic rest API. The local libnetwork code, the REST server that we have that serves the libnetwork ipam and remote driver APIs would live in kuryr-libnetwork. For the nested case, I'd put a configuration option to the libnetwork driver to prefer the vlan tagging binding script. >>> >>> vlan tagging part looks common to both libnetwork and k8s(cni). Will it >>> be present in both the repos, kuryr-libnetwork and kuryr-k8s or we can put >>> this also in common 'Kuryr'? >>> >> >> It would be in common kuryr. The configuration option to use it instead >> of the port type would be defined in both kuryr-libnetwork and kuryr-k8s. >> >> > > Thanks for the confirmation Toni. Now it totally makes sense. > > >>> Both CNI and the API watcher I would put in the kuryr-kubernetes repositories under /kuryr/{cni,watcher} >>> > > >> Fawad Khaliq >> >> >> On Fri, Jun 24, 2016 at 9:45 AM, Vikas Choudhary < >> choudharyvika...@gmail.com> wrote: >> >>> Hi Team, >>> >>> As already discussed with some of teammates over irc and internally, >>> thought of bringing discussionto ml for more opinions: >>> >>> My idea on repo structure is something similar to this: >>> >>> kuryr >>> └── controller >>> │ ├── api (running on controller node(cluster master or openstack >>> controller node), talking to other services(neutron)) >>> │ │ >>> │ ├── kubernetes-controller >>> │ │ │ >>> │ │ └── watcher (for network related services making api >>> calls) >>> │ │ >>> │ │___any_other_coe_controller_capable_of_watching_events >>> │ >>> │ >>> │ >>> │___driver >>> │common (traffic tagging utilities and binding) >>> │ >>> │kubernetes(cni) >>> │ >>> │libnetwork(network and ipam driver)(for network related >>> services making api calls) >>> │ >>> │ any_other_driver(calling api for nw related services if >>> watcher not supported) >>> >>> >>> Thoughts? >>> >>> >>> -Vikas >>> >>> >>> >>> >>> -- Forwarded message -- >>> From: Vikas Choudhary >>> Date: Thu, Jun 23, 2016 at 2:54 PM >>> Subject: Re: Kuryr Refactoring into common library and >>> kuryr-libnetwork + Nested_VMs >>> To: Antoni Segura Puimedon >>> >>> >>> @Toni, Can you please explain a bit on how the roles regarding >>> vlan/segmentation id allocation, tagging ang untagging containers' >>> traffic >
[openstack-dev] Syntribos Error : AttributeError: 'tuple' object has no attribute 'headers'
Link: https://openstack.nimeyo.com/89478/?show=89478#q89478 From: run2obtain Hi... I tried to use OpenStack Syntribos today for security testing against my devstack kilo cloud. I followed installation and configuration instructions provided at the openstack syntribos repo .Unfortunately, I received some errors after running the command : syntribos keystone.config .opencafe/templates/keystone/roles_get.txt . The errors are File "/usr/local/lib/python2.7/dist-packages/syntribos/extensions/identity/client.py", line 146, in get_token_v3 return r.headers["X-Subject-Token"] AttributeError: 'tuple' object has no attribute 'headers'. ' I have not been successful at discovering what could be wrong or how to resolve this issue, even after googling. Does anyone have a hint as to how to resolve this issue. Many thanks for your anticipated response. __ 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
Re: [openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?
On Jul 2, 2016 10:37 AM, "Dan Smith" wrote: > > > The question is whether we should do something like this: > > > > 1) As part of the normal execution of the service playbooks; > > 2) As part of the automated major upgrade (i.e. The step is not optional); > > 3) As part of the manual major upgrade (i.e. The step is optional); > > 4) Never. > > I am not an operator, but I would think that #4 is the right thing to > do. If I want to purge the database, it's going to be based on billing > reasons (or lack thereof) and be tied to another archival, audit, etc > policy that the "business people" are involved with. Install and > configuration of my services shouldn't really ever touch my data other > than mechanical upgrade scripts and the like, IMHO. > > Purging the database only during upgrades is not sufficient for large > installs, so why artificially tie it to that process? In Nova we don't > do data migrations as part of schema updates anymore, so it's not like a > purge is going to make the upgrade any faster... I agree with this sentiment. If OSA feels like it must provide automation for purging databases, it should be in the ops repo mentioned earlier. I see no reason to over extend upgrades with something not inherently necessary or appropriate for upgrades. -- Ian __ 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
Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration
Stephen, Responses inline. On 7/1/16, 11:35 AM, "Stephen Hindle" wrote: >Maybe I missed it - but is there a way to provide site specific >configurations? Things we will run into in the wild include: >Configuring multiple non-openstack nics We don¹t have anything like this at present or planned. Would you mind explaining the use case? Typically we in the Kolla community expect a production deployment to only deploy OpenStack, and not other stacks on top of the bare metal hardware. This is generally considered best practice at this time, unless of course your deploying something on top of OpenStack that may need these nics. The reason is that OpenStack itself managed alongside another application doesn¹t know what it doesn't know and can't handle capacity management or any of a number of other things required to make an OpenStack cloud operate. > IPMI configuration BiFrost includes IPMI integration - assumption being we will just use whatever BiFrost requires here for configuration. > Password integration with Corporate LDAP etc. We have been asked several times for this functionality, and it will come naturally during either Newton or Occata. > Integration with existing SANs Cinder integrates with SANs, and in Newton, we have integration with iSCSI. Unfortunately because of some controversy around how glance should provide images with regards to cinder, using existing SAN gear with iSCSI integration as is done by Cinder may not work as expected in a HA setup. > Integration with existing corporate IPAM No idea > Corporate Security policy (firewall rules, sudo groups, >hosts.allow, ssh configs,etc) This is environmental specific and its hard to make a promise on what we could deliver in a generic way that would be usable by everyone. Therefore our generic implementation will be the "bare minimum" to get the system into an operational state. The things listed above are outside the "bare minimum" iiuc. > >Thats just off the top of my head - I'm sure we'll run into others. I >tend to think the best way >to approach this is to allow some sort of 'bootstrap' role, that could >be populated by the >operators. This should initially be empty (Kolla specific 'bootstrap' Our bootstrap playbook is for launching BiFrost and bringing up the bare metal machines with an SSH credential. It appears from this thread we will have another playbook to do the bare metal initialization (thiings like turning off firewalld, turning on chrony, I.e. Making the bare metal environment operational for OpenStack) I think what you want is a third playbook which really belongs in the domain of the operators to handle site-specific configuration as required by corporate rules and the like. >actions should be >in another role) to prevent confusion. > >We also have to be careful that kolla doesn't stomp on any non-kolla >configuration... Could you expand here. Kolla currently expects the machines under its control to be only OpenStack machines, and not have other applications running on them. Hope that was helpful. Regards -steve > > >On Thu, Jun 30, 2016 at 12:43 PM, Mooney, Sean K > wrote: >> >> >>> -Original Message- >>> From: Steven Dake (stdake) [mailto:std...@cisco.com] >>> Sent: Monday, June 27, 2016 9:21 PM >>> To: OpenStack Development Mailing List (not for usage questions) >>> >>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + >>> BiFrost integration >>> >>> >>> >>> On 6/27/16, 11:19 AM, "Devananda van der Veen" >>> >>> wrote: >>> >>> >At a quick glance, this sequence diagram matches what I >>> >envisioned/expected. >>> > >>> >I'd like to suggest a few additional steps be called out, however I'm >>> >not sure how to edit this so I'll write them here. >>> > >>> > >>> >As part of the installation of Ironic, and assuming this is done >>> >through Bifrost, the Actor should configure Bifrost for their >>> >particular network environment. For instance: what eth device is >>> >connected to the IPMI network; what IP ranges can Bifrost assign to >>> >physical servers; and so on. >>> > >>> >There are a lot of other options during the install that can be >>> >changed, but the network config is the most important. Full defaults >>> >for this roles' config options are here: >>> > >>> >https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro >>> s >>> >t-i >>> >ronic-install/defaults/main.yml >>> > >>> >and documentation is here: >>> > >>> >https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro >>> s >>> >t-i >>> >ronic-install >>> > >>> > >>> > >>> >Immediately before "Ironic PXE boots..." step, the Actor must perform >>> >an action to "enroll" hardware (the "deployment targets") in Ironic. >>> >This could be done in several ways: passing a YAML file to Bifrost; >>> >using the Ironic CLI; or something else. >>> > >>> > >>> >"Ironic reports success to the bootstrap operation" is ambiguous. >>> >Ironic does not currently support not
Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS
2016-07-02 20:42 GMT+02:00 jason : > Pip Package Name Supported By Centos CentOS Name Repo > Name > == > ansible yes > ansible1.9.noarchepel > docker-py yes > python-docker-py.noarchextras > gitdb yes > python-gitdb.x86_64epel > GitPython yes > GitPython.noarchepel > oslo.config yes > python2-oslo-config.noarch centos-openstack-mitaka > pbryes > python-pbr.noarch epel > setuptools yes > python-setuptools.noarchbase > six yes > python-six.noarch base > pycryptoyes > python2-crypto epel > graphvizno > Jinja2no (Note: Jinja2 2.7.2 will be installed as > dependency by ansible) > As one of RDO maintainer, I strongly invite kolla, not to use EPEL. It's proven very hard to prevent EPEL pushing broken updates, or push updates to fit OpenStack requirements. Actually, all the dependency above but ansible, docker and git python modules are in CentOS Cloud SIG repositories. If you are interested to work w/ CentOS Cloud SIG, we can add missing dependencies in our repositories. > > As above table shows, only two (graphviz and Jinja2) are not supported > by centos currently. As those not supported packages are definitly not > used by OpenStack as well as Daisy. So basicaly we can use pip to > install them after installing other packages by yum. But note that > Jinja2 2.7.2 will be installed as dependency while yum install > ansible, so we need to using pip to install jinja2 2.8 after that to > overide the old one. Also note that we must make sure pip is ONLY used > for installing those two not supported packages. > > But before you trying to use pip, please consider these: > > 1) graphviz is just for saving image depend graph text file and is not > used by default and only used in build process if it is configured to > be used. > > 2) Jinja2 rpm can be found at > http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I > think is suitable for CentOS. I have tested it. > > So, as far as Kolla deploy process concerned, there is no need to use > pip to install graphviz and Jinja2. Further more, if we do not install > Kolla either then we can get ride of pip totally! > > I encourage all of you to think about not using pip any more for > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files > may be overide back and force if not using them carefully. So not > using pip will make things easier and make jump server more cleaner. > Any ideas? > > > Thanks, > Zhijiang > > -- > Yours, > Jason > > __ > 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
Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS
On 2 July 2016 at 19:42, jason wrote: > > > As above table shows, only two (graphviz and Jinja2) are not supported > by centos currently. As those not supported packages are definitly not > used by OpenStack as well as Daisy. So basicaly we can use pip to > install them after installing other packages by yum. But note that > Jinja2 2.7.2 will be installed as dependency while yum install > ansible, so we need to using pip to install jinja2 2.8 after that to > overide the old one. Also note that we must make sure pip is ONLY used > for installing those two not supported packages. > > Whilst this appears to be accurate, it would probably not be an appropriate change for stable/mitaka. However, it is probably worth checking the current development focus Master, which will become Newton (kolla/docker/openstack-base/Dockerfile.j2) and seeing if this is still an issue. A bunch of Centos Binary improvements were made this current cycle to make more use of yum packages[0]. [0] https://github.com/openstack/kolla/commit/a8f3da204e6d6ae42b30c166d436d74064394a1b -- Kind Regards, Dave Walker __ 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-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS
Pip Package Name Supported By Centos CentOS Name Repo Name == ansible yes ansible1.9.noarchepel docker-py yes python-docker-py.noarchextras gitdb yes python-gitdb.x86_64epel GitPython yes GitPython.noarchepel oslo.config yes python2-oslo-config.noarch centos-openstack-mitaka pbryes python-pbr.noarch epel setuptools yes python-setuptools.noarchbase six yes python-six.noarch base pycryptoyes python2-crypto epel graphvizno Jinja2no (Note: Jinja2 2.7.2 will be installed as dependency by ansible) As above table shows, only two (graphviz and Jinja2) are not supported by centos currently. As those not supported packages are definitly not used by OpenStack as well as Daisy. So basicaly we can use pip to install them after installing other packages by yum. But note that Jinja2 2.7.2 will be installed as dependency while yum install ansible, so we need to using pip to install jinja2 2.8 after that to overide the old one. Also note that we must make sure pip is ONLY used for installing those two not supported packages. But before you trying to use pip, please consider these: 1) graphviz is just for saving image depend graph text file and is not used by default and only used in build process if it is configured to be used. 2) Jinja2 rpm can be found at http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I think is suitable for CentOS. I have tested it. So, as far as Kolla deploy process concerned, there is no need to use pip to install graphviz and Jinja2. Further more, if we do not install Kolla either then we can get ride of pip totally! I encourage all of you to think about not using pip any more for Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files may be overide back and force if not using them carefully. So not using pip will make things easier and make jump server more cleaner. Any ideas? Thanks, Zhijiang -- Yours, Jason __ 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
Re: [openstack-dev] [ovs-dev] The QoS feature minimum guaranteed bandwidth of OpenvSwitch not work
On Sat, Jul 02, 2016 at 03:17:21PM +, Xiao Ma (xima2) wrote: > Hi , Ben > > Thanks for your reply. > > I configured the bond0 using linux bond then the result is not good for > minimum guaranteed bandwidth. > But if I use ovs-vsctl add-bond to configure the bond0 interface, the result > is good. > If I use linux bond with linux tc, the tc works well also. > > However, most problems with QoS on Linux are not bugs in Open > vSwitch at all. They tend to be either configuration errors > (please see the earlier questions in this section) or issues with > > Could you send me the section link? https://github.com/openvswitch/ovs/blob/master/FAQ.md#quality-of-service-qos __ 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
Re: [openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?
> The question is whether we should do something like this: > > 1) As part of the normal execution of the service playbooks; > 2) As part of the automated major upgrade (i.e. The step is not optional); > 3) As part of the manual major upgrade (i.e. The step is optional); > 4) Never. I am not an operator, but I would think that #4 is the right thing to do. If I want to purge the database, it's going to be based on billing reasons (or lack thereof) and be tied to another archival, audit, etc policy that the "business people" are involved with. Install and configuration of my services shouldn't really ever touch my data other than mechanical upgrade scripts and the like, IMHO. Purging the database only during upgrades is not sufficient for large installs, so why artificially tie it to that process? In Nova we don't do data migrations as part of schema updates anymore, so it's not like a purge is going to make the upgrade any faster... --Dan __ 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
Re: [openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?
+1 "As part of the normal execution of the service playbooks" w/ user_variable to turn it on/off of course; whether it defaults to on or off is really designers choice. Some production clouds will have the playbooks ran against them frequently, others not so much. On Sat, Jul 2, 2016 at 7:43 AM Jesse Pretorius < jesse.pretor...@rackspace.co.uk> wrote: > On 7/1/16, 8:48 PM, "Ian Cordasco" wrote: > > > > >-Original Message- > >From: Jesse Pretorius > > > >> In a recent conversation on the Operators list [1] there was a > discussion about purging > >> archived data in the database. It would seem to me an important step in > maintaining an > >> environment which should be done from time to time and perhaps at the > very least prior > >> to a major upgrade. > >> > >> What’re the thoughts on how often this should be done? Should we > include it as an opt-in > >> step, or an opt-out step? > >> > >> [1] > http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html > > > >Is OpenStack-Ansible now going to get into the minutae of operating > >the entire cloud? I was under the impression that it left the easy > >things to the operators (e.g., deciding when and how to purge the > >database) while taking care of the things that are less obvious > >(setting up OpenStack, and interacting with the database directly to > >only set up things for the services). > > That’s a good question which betrays the fact that I phrased my question > poorly. :) > > The question is whether we should do something like this: > > 1) As part of the normal execution of the service playbooks; > 2) As part of the automated major upgrade (i.e. The step is not optional); > 3) As part of the manual major upgrade (i.e. The step is optional); > 4) Never. > > If never, it might be useful for our community to curate a few bits of > operations tooling to automated this sort of thing on demand. The tooling > can be placed into the Ops repository [1] if this is done. > > [1] https://github.com/openstack/openstack-ansible-ops > > > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy > can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail > message may contain confidential or privileged information intended for the > recipient. Any dissemination, distribution or copying of the enclosed > material is prohibited. If you receive this transmission in error, please > notify us immediately by e-mail at ab...@rackspace.com and delete the > original message. Your cooperation is appreciated. > __ > 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
Re: [openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?
On 7/1/16, 8:48 PM, "Ian Cordasco" wrote: >-Original Message- >From: Jesse Pretorius > >> In a recent conversation on the Operators list [1] there was a discussion >> about purging >> archived data in the database. It would seem to me an important step in >> maintaining an >> environment which should be done from time to time and perhaps at the very >> least prior >> to a major upgrade. >> >> What’re the thoughts on how often this should be done? Should we include it >> as an opt-in >> step, or an opt-out step? >> >> [1] >> http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html > >Is OpenStack-Ansible now going to get into the minutae of operating >the entire cloud? I was under the impression that it left the easy >things to the operators (e.g., deciding when and how to purge the >database) while taking care of the things that are less obvious >(setting up OpenStack, and interacting with the database directly to >only set up things for the services). That’s a good question which betrays the fact that I phrased my question poorly. :) The question is whether we should do something like this: 1) As part of the normal execution of the service playbooks; 2) As part of the automated major upgrade (i.e. The step is not optional); 3) As part of the manual major upgrade (i.e. The step is optional); 4) Never. If never, it might be useful for our community to curate a few bits of operations tooling to automated this sort of thing on demand. The tooling can be placed into the Ops repository [1] if this is done. [1] https://github.com/openstack/openstack-ansible-ops Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ 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
Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors
I was thinking on your reply for some time. I think I now have some constructive bits to add. > On 30 Jun 2016, at 18:50, Doug Wiegley wrote: > > >> On Jun 30, 2016, at 7:01 AM, Ihar Hrachyshka wrote: >> >> >>> On 30 Jun 2016, at 06:03, Kosnik, Lubosz 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. > You assume that operators and users don’t care about reference implementation and its internals. It can’t be further from truth. Architecture matters to operators, since it often defines how it’s used, if at all. Another thing that matters is whether the team behind the architecture provides compatibility guarantees for an extended period of time. You can’t just switch design every second cycle and expect operators and distributions to catch up. When you plan for a transition, backwards compatibility should be at the core of discussion. > 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.) That does not sound like a reasonable approach. Operators and distributions cannot be expected to adopt to your new cool ways every cycle. Please pick an implementation that is good enough and stick to it for extended time. Yes, I know lbaas project is generally more experimental (starting with v1, switching to v2, getting it out of experimental only to deprecate right away and switch end points to octavia that uses absolutely different reference architecture without providing any migration path, …) But maybe that’s not a thing to be proud of, and it’s time to stop. > > 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. There was always an expectation in neutron community that we provide reasonable plug points to vendors, both for distributions as well as networking vendors, and we accommodate to wide variety of technologies. > > 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. While Octavia itself is indeed pluggable, those plugging points are too high level, leaving alternative distributions to reimplement the whole stack. In that particular case, other distributions can indeed craft their own images with a customized amp agent. The problem is, by not giving us any real plugging points to leverage, we are effectively suggested to fork the whole agent. If that happens, I don’t think it will be of help to either party in the deal. > > That’s just my
Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors
> On 30 Jun 2016, at 06:03, Kosnik, Lubosz 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. I actually don’t see too much of mixing here; at least in the patch that Nir published, implementation specific details are nicely isolated per flavour. When we have Ubuntu with systemd case, we can easily reshuffle the code a bit more for better reuse. 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
Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
Thank you Matt and Armando for additional background information, and offer to help us. We really appreciate it. Let me explain our requirement a bit. We are telco operators, and we are moving toward NFV domain, which is a whole new domain of business and technology. New domain means 2 folds - Brand new business opportunities and market segments - Brand new technologies that need exploration and experiment, especially in NFV networking. NFV brings opportunities, which also means new challenges. For example, there are new NFV networking use cases today, such as MPLS and L3VPN. But more importantly, because of the **green field** nature of NFV, we foresee there will be whole new NFV networking use cases (that bring new business) in near future. And the challenge to us is to: - Quickly catch the business opportunity - Execute it in agile way so that we can accelerate the time-to-market and improve our business agility in offering our customers with those new NFV services. “Interoperability” is always our favorite term. Being an operator, we know how important the interoperability is. Without interoperability, there is no global mobile network for users to have one device and connect anywhere. However, in a **green field** of NFV, when the services and technologies is being developed, and every service provider is offering diversified, innovative services and brings to the customers in an agile way, “interoperability” is not a top priority at this moment IMHO. Quick development and deployment, time-to-market and business agility is the key to grow everyone’s business in the **green field**. When NFV services get stabilized at later stage, then we need to emphasize the “interoperability” at that time. All of the background brings an interesting challenge to Nova and Neutron too – how can we better balance the need of interoperability (i.e. tight control) v.s. the need of penetrating new market opportunity of NFV green field (i.e. wild west)? That is why we developed Gluon, a model-driven, extensible framework for NFV networking services. This framework aims to: - Work with and interoperate with Neutron for any existing networking services that Neutron is supporting today - Provides extensibility to support new, unknown NFV networking services in green field in an agile way, i.e. NFV networking on-demand. Think about early days of Nova networking, everything was exploratory and experimental. It gets matured over time. In a green field of NFV networking, we need exploration and experiment too, because it encourages innovation. When a NFV service gets matured, we focus on its interoperability then. We are looking forward to working with Nova and Neutron team to consolidate Gluon with Nova and Neutron. The goal is to - Make sure current interoperability model of stable APIs and services will keep as is - Make sure current networking services and ongoing effort supported by Neutron will keep going as is - Allow an extensibility model/framework (Gluon), which can connect with Nova and Neutron too, for us to explore the green field in NFV networking services and business in an agile way, and meet the time-to-market need, because of its **unknown* nature of new, innovative services in NFV green field - Whenever NFV networking services and business get stabilized and matured, turn it to interoperability model for those stable APIs and services as we are currently doing Let me know what you think and we are looking forward to working with you. Thanks Bin From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, July 01, 2016 3:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release On 30 June 2016 at 10:55, HU, BIN mailto:bh5...@att.com>> wrote: I see, and thank you very much Dan. Also thank you Markus for unreleased release notes. Now I understand that it is not a plugin and unstable interface. And there is a new "use_neutron" option for configuring Nova to use Neutron as its network backend. When we use Neutron, there are ML2 and ML3 plugins so that we can choose to use different backend providers to actually perform those network functions. For example, integration with ODL. There's no such a thing as ML3, not yet anyway and not in the same shape of ML2. Shall we foresee a situation, where user can choose another network backend directly, e.g. ODL, ONOS? Under this circumstance, a stable plugin interface seems needed which can provide end users with more options and flexibility in deployment. The networking landscape is dramatically different from the one Nova experiences and even though I personally share the same ideals and desire to strive for interoperability across OpenStack clouds, the Neutron team is generally more open to providing extensib