[openstack-dev] [Cinder] Question about storage backend capacity expansion
Hi, all: I meet a requirement in my OpenStack environment which initially uses one LVMISCSI backend. Along with the usage, the storage is insufficient, so I want to add a NFS backend to the exists Cinder. There is only a single Cinder-volume in environment, so I need to configure the Cinder to use multi-backend, which means the initial LVMISCSI storage and the new added NFS storage are both used as the backend. However, the existing volume on initial LVMISCSI backend will not be handled normally after using multi-backend, because the host of the exists volume will be thought down. I know that the migrate and retype APIs aim to handle the backend capacity expansion, however, each of them can't used for this situation. I think the use case above is common in production environment. Is there some existing method can achieve it ? Currently, I manually updated the host value of the existing volumes in database, and the existing volumes can then be handled normally. Thanks. -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Modification of a running swift setup...
Hi, After setup and usage of a two-node swift cluster, let's say I want to rebuild the rings with zones and regions differently mapped. I mean, I initially mapped disk1a and disk1b in node1 to zone1 and disk2a and disk2b in node2 to zone2; and now want to change the setup to each disk in a different zone. Is this sort of modification possible on a running swift cluster, without (or minimal) interruption in service? If so, how do I do it. Thanks in advance for your replies. -- -Shyam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Scaling Network Performance for Large Clouds: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor
Dear Stackers, Oops, the complete link of that BP should be below. https://blueprints.launchpad.net/neutron/+spec/scaling-network-performance Thank you, Tina From: Tina TSOU Sent: Tuesday, May 13, 2014 10:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Scaling Network Performance for Large Clouds: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor Dear Stackers, We are setting up a meeting to discuss Scaling Network Performance for Large Clouds. There are already cases from eBay, Yahoo and Huawei customers. Here is related BP: https://blueprints.launchpad.net/neutron/+spec/scaling-network-perform The meeting is planned for: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor Look forward to talking to many of you then. Thank you, Tina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] canceling team meeting May 15
Hey team, Just a reminder, the tomorrow's meeting (May 15) is canceled due to the OpenStack Summit in Atlanta. Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] B203 table 6 for Neutron//Re: Scaling Network Performance for Large Clouds: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor
Dear all, Place is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area. Thank you, Tina On May 14, 2014, at 8:00 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Stackers, Oops, the complete link of that BP should be below. https://blueprints.launchpad.net/neutron/+spec/scaling-network-performance Thank you, Tina From: Tina TSOU Sent: Tuesday, May 13, 2014 10:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Scaling Network Performance for Large Clouds: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor Dear Stackers, We are setting up a meeting to discuss Scaling Network Performance for Large Clouds. There are already cases from eBay, Yahoo and Huawei customers. Here is related BP: https://blueprints.launchpad.net/neutron/+spec/scaling-network-perform The meeting is planned for: Thursday May 15th at 10:30-11am in the developer lounge at 3rd floor Look forward to talking to many of you then. Thank you, Tina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] 3rd party CI requirements for DB2
I'd like to get some more discussion going for the nova-spec on adding DB2 support [1] especially since we didn't get to the topic for non-virt driver 3rd party CI in the nova design summit session this morning. Basically, there are three possible 3rd party CIs to run for a backend database engine: 1. tempest 2. unit tests 3. turbo-hipster In Icehouse we were working toward Tempest with 3rd party CI and it's running against the WIP patch [2] already. Now the question is coming up about whether or not unit test and t-h are also requirements for inclusion in Juno. Obviously it's in everyone's best interest to run all three and get the most coverage possible to feel warm and fuzzy, but to be realistic I'd like to prioritize in the same order above, but then the question is if it's acceptable to stagger the UT and t-h testing. A couple of points: 1. The migration unit tests under nova.tests.db.api will/should cover new tables and wrinkles, but I'd argue that Tempest should already be testing new tables (and you're getting the biggest test in my experience which is actually running the DB migrations when setting up with 'nova-manage db sync'). So I consider UT a lower priority and therefore defer-able to a later release. 2. t-h testing is also desirable, but (a) there are no other 3rd party CI systems running t-h like they do for Tempest and (b) t-h is only running MySQL today, not PostgreSQL which is already in tree. Given that, I also consider t-h testing defer-able and lower priority than getting unit tests running against a DB2 backend. If we can agree on those priorities, then I'd like to figure out timelines and penalties, i.e. when would UT/t-h 3rd party CI be required for DB2, e.g. UT in K, t-h in H? And if those deadlines aren't met, what's the penalty? Since the DB2 support is baked into the migration scripts, I'm not sure how you can really just rip it out like a virt driver. The obvious thing to me is you just stop accepting any migration changes that are for DB2 support, so new migrations could be broken on DB2 and they don't get fixed until the CI requirements are met. Any voting CI system would also be turned off from voting/reporting. Additional thoughts here? [1] https://review.openstack.org/#/c/87096/ [2] https://review.openstack.org/#/c/69047/ -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [MagnetoDB] Bulk load API draft
Hi openstackers, I'm working on bulk load for MagnetoDB, the facility for inserting large amounts of data, like, millions of rows, gigabytes of data. Below is the link to draft API description. https://wiki.openstack.org/wiki/MagnetoDB/bulkload#.5BDraft.5D_MagnetoDB_Bulk_Load_workflow_and_API Any feedback is welcome. -- Best regards, Illia Khudoshyn, Software Engineer, Mirantis, Inc. 38, Lenina ave. Kharkov, Ukraine www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru Skype: gluke_work ikhudos...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor
Dear all, Place is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area. Thank you, Tina On May 13, 2014, at 10:00 PM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Stackers, We are setting up a meeting to SDN NBI Core APIs consumed by OpenStack. Attached is the material for your reading pleasure. The meeting is planned for: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor . Look forward to meeting many of you then. Thank you, Tina NBI Core APIs.docx ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
- Original Message - From: Joe Gordon joe.gord...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 4:54:31 PM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com To: openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto: jamielen...@redhat.com wrote: All, TL;DR: novaclient should be able to use the common transport/auth layers of keystoneclient. If it does there are going to be functions like client.authenticate() that won't operate the same way when a session object is passed. For most users who just use the CRUD operations there will be no difference. I'm hoping that at least some of the nova community has heard of the push for using keystoneclient's Session object across all the clients. For those unaware keystoneclient.session.Session is a common transport and authentication layer to remove the need for each python-*client having there own authentication configuration and disparate transport options. It offers: - a single place for updates to transport (eg fixing TLS or other transport issues in one place) - a way for all clients to immediately support the full range of keystone's authentication including v3 auth, SAML, kerberos etc - a common place to handle version discovery such that we support multiple version endpoints from the same service catalog endpoint. For information of how to interact with a session you can see: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ This mentions the code is uncommitted however has since been committed with a few small details around parameter names being changed. The theory remains the same. To integrate this into novaclient means that if a session= object is passed then the standard HTTPClient code will be ignored in favour of using what was passed. This means that there are changes in the API of the client. In keystoneclient we have take the opinion that by passing a session object then you opt-in to the newer API and therefore accept that some functions are no longer available. For example client.authenticate() is no longer allowed because authentication is not the client's responsibility. It will have no impact on the standard novaclient CRUD operations and so be un-noticed by the vast majority of users. The review showing these changes is here: https://review.openstack.org/#/c/85920 To enable this there are a series of test changes to mock client requests at the HTTP layer rather than in the client. This means that we can test that all client operations against the new and old client construction methods and ensure the same requests are being sent. The foundation of this to turn tests into fixtures can be found by following: https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing IMO making these tests into fixtures is a good idea anyway, however I am only pursuing it so that we can transition to using a common Session. Regarding dependencies, novaclient will need a test-requirements.txt on keystoneclient so that it can construct Session objects to test with but it should not need a requirements.txt as the session object is constructed by the user of the client (eg openstackclient, horizon etc). Can we make novaclient use keystoneclient's session by default? And just add this to requirements. ++ Once it's supported, I would think that someone wanting to use novaclient _without_ keystoneclient should be seen as the exception case and not the normal case. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url=' http://keystone/v3 ', username='user', password='pass', ...) session = keystoneclient.session.Session(auth=auth, cacerts='path/to') glance = glanceclient.v1.Client(session) keystone = keystoneclient.v3.Client(session) nova = novaclient.v1.Client(session) This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said that the
Re: [openstack-dev] [oslo][db] oslo.db repository review request
Le mardi 13 mai 2014, 07:31:34 Doug Hellmann a écrit :
Since we think we have been able to solve all of the issues we were
having with namespace packages before, ...
I just tried to start my DevStack and again, I had issues with a builtin
olso module: import oslo.config doesn't work, whereas olso.config was
installed (system wide) by pip.
pip list|grep olso told me that oslo.config, oslo.messaging, oslo.rootwrap
and oslo.vmware are installed.
My workaround is to uninstall all olso modules:
sudo pip uninstall oslo.config oslo.messaging oslo.rootwrap oslo.vmware
./stack.sh reinstalls them and now it works.
--
Current state:
haypo@devstackdev$ pip list|grep oslo
oslo.config (1.3.0a0.40.gb347519)
oslo.messaging (1.3.0.8.gc0c8557)
oslo.rootwrap (1.2.0)
oslo.vmware (0.3.1.g49097c0)
haypo@devstackdev$ python
Python 2.7.5 (default, Feb 19 2014, 13:47:28)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
Type help, copyright, credits or license for more information.
import oslo
oslo
module 'oslo' (built-in)
import oslo.config
import oslo.messaging
import oslo.rootwrap
import oslo.vmware
I never understood how these .pth files work.
haypo@devstackdev$ cd /usr/lib/python2.7/site-packages
haypo@devstackdev$ ls oslo*.pth -1
oslo.config-1.3.0a0.40.gb347519-py2.7-nspkg.pth
oslo.messaging-1.3.0.8.gc0c8557-py2.7-nspkg.pth
oslo.rootwrap-1.2.0-py2.7-nspkg.pth
oslo.vmware-0.3.1.g49097c0-py2.7-nspkg.pth
haypo@devstackdev$ md5sum oslo*.pth
002fd4bf040a30d396d4df8e1ed378a8 oslo.config-1.3.0a0.40.gb347519-py2.7-
nspkg.pth
002fd4bf040a30d396d4df8e1ed378a8 oslo.messaging-1.3.0.8.gc0c8557-py2.7-
nspkg.pth
002fd4bf040a30d396d4df8e1ed378a8 oslo.rootwrap-1.2.0-py2.7-nspkg.pth
002fd4bf040a30d396d4df8e1ed378a8 oslo.vmware-0.3.1.g49097c0-py2.7-nspkg.pth
haypo@devstackdev$ cat oslo.config-1.3.0a0.40.gb347519-py2.7-nspkg.pth
import sys,types,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'],
*('oslo',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m = not ie
and sys.modules.setdefault('oslo',types.ModuleType('oslo')); mp = (m or [])
and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
Victor
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
On May 14, 2014, at 12:14 AM, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: Hi, all: I meet a requirement in my OpenStack environment which initially uses one LVMISCSI backend. Along with the usage, the storage is insufficient, so I want to add a NFS backend to the exists Cinder. There is only a single Cinder-volume in environment, so I need to configure the Cinder to use multi-backend, which means the initial LVMISCSI storage and the new added NFS storage are both used as the backend. However, the existing volume on initial LVMISCSI backend will not be handled normally after using multi-backend, because the host of the exists volume will be thought down. I know that the migrate and retype APIs aim to handle the backend capacity expansion, however, each of them can't used for this situation. I think the use case above is common in production environment. Is there some existing method can achieve it ? Currently, I manually updated the host value of the existing volumes in database, and the existing volumes can then be handled normally. While the above use case may be common, you are explicitly changing the config of the system, and requiring a manual update of the database in this case seems reasonable to me. Vish Thanks. -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multiple instances of Keystone
Keystone has specifically avoided including multiple process patches because they want to encourage apache + mod_wsgi as the standard way of scaling the keystone api. Vish On May 13, 2014, at 9:34 PM, Aniruddha Singh Gautam aniruddha.gau...@aricent.com wrote: Hi, Hope you are doing well… I was working on trying to apply the patch for running multiple instance of Keystone. Somehow it does not work with following errors, I wish to still debug it further, but thought that I will check with you if you can provide some quick help. I was following http://blog.gridcentric.com/?Tag=Scalability. I did the changes on Ice House GA. Error Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py, line 119, in wait x.wait() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py, line 47, in wait return self.thread.wait() File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 168, in wait return self._exit_event.wait() File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait return hubs.get_hub().switch() File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 187, in switch return self.greenlet.switch() File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, in main result = function(*args, **kwargs) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 449, in run_service service.start() AttributeError: 'tuple' object has no attribute 'start' (keystone): 2014-05-13 08:17:37,073 CRITICAL AttributeError: 'tuple' object has no attribute 'stop' Traceback (most recent call last): File /usr/bin/keystone-all, line 162, in module serve(*servers) File /usr/bin/keystone-all, line 111, in serve launcher.wait() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 352, in wait self._respawn_children() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 342, in _respawn_children self._start_child(wrap) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 282, in _start_child status, signo = self._child_wait_for_exit_or_signal(launcher) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 240, in _child_wait_for_exit_or_signal launcher.stop() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 95, in stop self.services.stop() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 419, in stop service.stop() AttributeError: 'tuple' object has no attribute 'stop' In logs I can find the new child processes, somehow probably they are stopped and then it spawns another child processes. I also noticed that support for running multiple neutron servers in ICE House GA. Any specific reason of not having same thing for Keystone (My knowledge of Openstack is limited, so please bear with my dumb questions) Best regards, Aniruddha DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Discuss Open CDN in Atlanta?
Hi folks, Is there anyone attending the Atlanta Summit that has interest and energy in CDN as it relates to the OpenStack ecosystem? We're thinking about a project that allows CDN vendors to unite under a common open API -- much like storage vendors can write drivers that are compatible with the Cinder API. If you're interested, reply directly off-list and I'll find us a time and place to discuss further. If you're interested but not at the summit, let me know that as well -- we'll find a way to loop you in. Allan Metts, Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][QoS] Reminder - 2:30 PM tomorrow at the Networking pod
Be there or be square :) -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM
I also intend on advertising this during the core-refactoring session in the etherpad. Please pay attention to that if you're there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multiple instances of Keystone
If you are using devstack, it's simple to enable Keystone+Apache Httpd [1] APACHE_ENABLED_SERVICES+=key -- dims [1] https://github.com/openstack-dev/devstack/blob/master/README.md On Wed, May 14, 2014 at 11:46 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Keystone has specifically avoided including multiple process patches because they want to encourage apache + mod_wsgi as the standard way of scaling the keystone api. Vish On May 13, 2014, at 9:34 PM, Aniruddha Singh Gautam aniruddha.gau...@aricent.com wrote: Hi, Hope you are doing well… I was working on trying to apply the patch for running multiple instance of Keystone. Somehow it does not work with following errors, I wish to still debug it further, but thought that I will check with you if you can provide some quick help. I was following http://blog.gridcentric.com/?Tag=Scalability. I did the changes on Ice House GA. Error Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py, line 119, in wait x.wait() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py, line 47, in wait return self.thread.wait() File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 168, in wait return self._exit_event.wait() File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait return hubs.get_hub().switch() File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 187, in switch return self.greenlet.switch() File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, in main result = function(*args, **kwargs) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 449, in run_service service.start() AttributeError: 'tuple' object has no attribute 'start' (keystone): 2014-05-13 08:17:37,073 CRITICAL AttributeError: 'tuple' object has no attribute 'stop' Traceback (most recent call last): File /usr/bin/keystone-all, line 162, in module serve(*servers) File /usr/bin/keystone-all, line 111, in serve launcher.wait() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 352, in wait self._respawn_children() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 342, in _respawn_children self._start_child(wrap) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 282, in _start_child status, signo = self._child_wait_for_exit_or_signal(launcher) File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 240, in _child_wait_for_exit_or_signal launcher.stop() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 95, in stop self.services.stop() File /usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py, line 419, in stop service.stop() AttributeError: 'tuple' object has no attribute 'stop' In logs I can find the new child processes, somehow probably they are stopped and then it spawns another child processes. I also noticed that support for running multiple neutron servers in ICE House GA. Any specific reason of not having same thing for Keystone (My knowledge of Openstack is limited, so please bear with my dumb questions) Best regards, Aniruddha DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Minutes from meeting around Advanced Services (particularly LBaaS) and Neutron
All, Thank you for attending the meeting around the Advanced Services and Neutron yesterday in the Neutron pod. We had a great meeting. The goal of this session was to discuss how the current Neutron LBaaS doesn't fit the need of what is now defined as operators e.g. large scale (private, public) cloud service providers. Background info on Why we needed this session can be found at: https://etherpad.openstack.org/p/AdvancedServices_and_Neutron More than 60 people attended and we had representtives from many companies incl. PayPal, Yahoo, Rackspace, BlueBox, HP, Comcast, Intel, F5, and many more. We had several Neutron core team members incl the current PTL Kyle Mestery, the previous PTL Mark McClain, Maru Newby and leads for the Advanced services Sumit Naiksatam and Nachi Ueno. Several issues were discussed including the lack of velocity and progress in the LBaaS project, the operator requirements and prioritization documented on the Wiki, operator use cases documented on the wiki, lack of architectural and design documentations, issues around being able to contribute to the project, etc... A lot of frustration was aired and in the end the neutron core team members signed up to help get LBaaS/Advanced services back on track by educating the newcomers, by helping unblock issues, and by helping speed up the review process. Outcomes from the Meeting Immediate action items: * The Neutron team will assign a core team member to facilitate the dialog with the LBaaS team to mentor the LBaaS newcomers through the various processes including what it takes to become a core member. -- Kyle Mestery signed up to be this liaison person/dedicated core reviewer since he has already started attending the various LBaaS weekly meetings. Thanks Kyle :-) * The Neutron core team will provide a list of the plug-in integration points that are problematic. Owner: Kyle Short term goals (Juno) * Create a better abstraction between the Advanced Services and Neutron core. * Well-defined and clean interfaces * Clean REST API for User (will be discussed Thursday 11:00-11:40 during the LBaaS Session) * Mentorship Long term goal (~3 release cycles) * Spin-out LBaaS from Neutron (with all the things that include: clean architecture, QA, etc...) We plan to revisit this goal at each summit to track our progress against it. Regards Susanne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [solum] Solum roadmap for review
I updated the high level roadmap for the program and the project vision https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap Let us use the Solum workshop meeting today to go over and refine it. Thanks Regards, Roshan Agrawal Direct: 512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
Thanks for your reply and advice. Manual update of the database can achieve it, however, I don't think it is reasonable especially in a production environment. 2014-05-14 23:43 GMT+08:00 Vishvananda Ishaya vishvana...@gmail.com: On May 14, 2014, at 12:14 AM, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: Hi, all: I meet a requirement in my OpenStack environment which initially uses one LVMISCSI backend. Along with the usage, the storage is insufficient, so I want to add a NFS backend to the exists Cinder. There is only a single Cinder-volume in environment, so I need to configure the Cinder to use multi-backend, which means the initial LVMISCSI storage and the new added NFS storage are both used as the backend. However, the existing volume on initial LVMISCSI backend will not be handled normally after using multi-backend, because the host of the exists volume will be thought down. I know that the migrate and retype APIs aim to handle the backend capacity expansion, however, each of them can't used for this situation. I think the use case above is common in production environment. Is there some existing method can achieve it ? Currently, I manually updated the host value of the existing volumes in database, and the existing volumes can then be handled normally. While the above use case may be common, you are explicitly changing the config of the system, and requiring a manual update of the database in this case seems reasonable to me. Vish Thanks. -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [MagnetoDB] Design session followup
Hello everybody, Thank you for coming to MagnetoDB design session. It is very important to hear your feedback. If you missed the session somehow you can look at the presentation here http://www.slideshare.net/zaletniy/openstack-magnetodb-atlanta-2014-keyvalue -storage-openstack-usecases Demo script for Postman REST clienthttps://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcmis available by link https://www.getpostman.com/collections/b50a9fda5560fedc4a16 If you have any questions feel free to catch me during design summit Ilya Sviridov isviridov @ FreeNode ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM
John Voss and I believe Thursday (May 15) would be the best time to do this. I will write it on the board. On 5/14/14 11:59 AM, Justin Hammond justin.hamm...@rackspace.com wrote: I also intend on advertising this during the core-refactoring session in the etherpad. Please pay attention to that if you're there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][NFV] NFV BoF at design summit
Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM
Signed up for 11:30 AM, May 14 at the neutron POD. On 5/14/14 12:29 PM, Justin Hammond justin.hamm...@rackspace.com wrote: John Voss and I believe Thursday (May 15) would be the best time to do this. I will write it on the board. On 5/14/14 11:59 AM, Justin Hammond justin.hamm...@rackspace.com wrote: I also intend on advertising this during the core-refactoring session in the etherpad. Please pay attention to that if you're there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor
Tina, That was a good conversation. Would you be available for some additional followup on the L3 VPN topic at 4:00 today? I have a coworker who wasn't available for the discussion earlier today. Original message From: Tina TSOU tina.tsou.zout...@huawei.com Date: To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: paul.car...@att.com,mmccl...@yahoo-inc.com,Louis.Fourie louis.fou...@huawei.com Subject: Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor Dear all, Below is the main conclusion from this meeting. We will work on the following SDN NBI Core APIs at the priority per Neutron's interest. 2, 7, 10, 9, 11. 1.2 APIs for connection between OpenStack Neutron and controller OpenStack is widely used and deployed in cloud scenarios.OpenStack-based data center is becoming mainstream. There should be APIs for connection between SDN controller and OpenStack Neutron. 1.7 APIs for Virtual-Tenant-Network (VTN) VTN allows users and developers to design and deploy virtual networks without the need to know the physical network. This is very useful in data center. There should be APIs for virtual tenant network. 1.10 APIs for QoS QoS is usually for end user application. For example, the UC-SDN-Use-Case needs the network to guarantee its flow QoS to improve the user’s QoE. There should be APIs for QoS. 1.9 APIs for VPN VPN is also widely use in enterprise network, interconnectionbetween data centers and mobile environments. The management and operation of VPN are necessary. There should be APIs for VPN. The VPN may include the following type L2 VPN L3 VPN 1.11 APIs for network stats/state The network stats/state is needed by application so that the application can react with the corresponding policy. There should be APIs for network stats/state. Thank you, Tina On May 14, 2014, at 10:00 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear all, Place is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area. Thank you, Tina On May 13, 2014, at 10:00 PM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Stackers, We are setting up a meeting to SDN NBI Core APIs consumed by OpenStack. Attached is the material for your reading pleasure. The meeting is planned for: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor . Look forward to meeting many of you then. Thank you, Tina NBI Core APIs.docx ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Meet Murano developers at Atlanta summit
We've seen a lot of interest in Murano at the Atlanta summit. In case if you would like to learn more, please stop by Mirantis booth (1st level) tomorrow (Thursday) from from 3PM to 5PM. Murano developers will be there and they will be happy to show you the demo in give more details. -- Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor
Dear Paul, Thanks for your sharing of ATT experience and your thoughts. Sure, let's meet at B203 table 6 for Neutro at 4pm today, for followup on the L3 VPN topic. Thank you, Tina On May 14, 2014, at 1:29 PM, CARVER, PAUL pc2...@att.commailto:pc2...@att.com wrote: Tina, That was a good conversation. Would you be available for some additional followup on the L3 VPN topic at 4:00 today? I have a coworker who wasn't available for the discussion earlier today. Original message From: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Date: To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: paul.car...@att.commailto:paul.car...@att.com,mmccl...@yahoo-inc.commailto:mmccl...@yahoo-inc.com,Louis.Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Subject: Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor Dear all, Below is the main conclusion from this meeting. We will work on the following SDN NBI Core APIs at the priority per Neutron's interest. 2, 7, 10, 9, 11. 1.2 APIs for connection between OpenStack Neutron and controller OpenStack is widely used and deployed in cloud scenarios.OpenStack-based data center is becoming mainstream. There should be APIs for connection between SDN controller and OpenStack Neutron. 1.7 APIs for Virtual-Tenant-Network (VTN) VTN allows users and developers to design and deploy virtual networks without the need to know the physical network. This is very useful in data center. There should be APIs for virtual tenant network. 1.10 APIs for QoS QoS is usually for end user application. For example, the UC-SDN-Use-Case needs the network to guarantee its flow QoS to improve the user’s QoE. There should be APIs for QoS. 1.9 APIs for VPN VPN is also widely use in enterprise network, interconnectionbetween data centers and mobile environments. The management and operation of VPN are necessary. There should be APIs for VPN. The VPN may include the following type L2 VPN L3 VPN 1.11 APIs for network stats/state The network stats/state is needed by application so that the application can react with the corresponding policy. There should be APIs for network stats/state. Thank you, Tina On May 14, 2014, at 10:00 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear all, Place is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area. Thank you, Tina On May 13, 2014, at 10:00 PM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Stackers, We are setting up a meeting to SDN NBI Core APIs consumed by OpenStack. Attached is the material for your reading pleasure. The meeting is planned for: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor . Look forward to meeting many of you then. Thank you, Tina NBI Core APIs.docx ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [designate] FW: The Decline and Fall of Bind 10
On 5/14/14, 1:33 PM, Mike Sisk mike.s...@rackspace.com wrote: https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10. pdf ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [golang-client] Tentative Design Decisions
The golang-client/openstack-sdk-go is an SDK written in Go to operate against OpenStack REST APIs. The project sits in stackforge and in one of a number of Go clients for OpenStack. This email is here to describe what we're doing and some base design decisions. First, if there are Go clients for OpenStack why is there another effort in Stackforge? The existing clients don't meet all the requirements and there are a number of cases where they fall short. For example, none of the existing clients support multiple REST API versions. They were written against the versions for a particular stack. We need an SDK that handles this cleanly. Ideally, we'd like to pull in working code from existing projects where the license will allow us to do so. Some tentative decisions (speak now if you don't agree). When it comes to directory/package structure we'd use something similar to the way python does it. That is a directory for each service (e.g., identity, compute, etc) with another directory in there for each version. This way we can handle versions like identity v2, v3, and v4 at the same time. Since Go is statically typed it would be useful to have a common interface for base service operations. For example, compute instances need to be created, destroyed, restarted, and a handful of other service. Each API version would/should implement some of these base operations, though in different ways. An interface that implements these would be useful for applications that use the SDK. The transport client would be pluggable and dependency injected but have a same default. It would likely be the built in system to go. But, we need flexibility here. For example, an application may communicate with a public cloud through a proxy while communicating with a private cloud compute endpoint bypassing the proxy. The flexibility to implement that needs to be in place. This means managers for service will be needed in packages so the same manager can be instantiated twice with different transport layers. The Python SDK is using an ORB style for working with services. This isn't something we've seen happen much in Go. Instead we're looking at the manager/resource style setup to be in a manner more common to the language. As I said earlier, where ever we can re-use code from existing projects we'd like to try and do so. Some places there is flexibility to do some. Some other places licenses (such at the GPLv3) will limit code reuse and we're going to pay attention to that. If you have any comments, questions, or want to get involved please jump in. - Matt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Cancelling weekly meeting 15 of May
Hi, Let's skip the meeting this week for obvious reasons :) Also, Oleg and me will not be able to attend the meeting next week (if it will be conducted), because we will be on vocation. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [designate] meeting in room 203 for more design work
Sorry, I misspelled ³designate² (again) last time I sent this. On 5/14/14, 4:21 PM, Joe Mcbride jmcbr...@rackspace.com wrote: Hello all, If you are still at the conference today (May 14), we invite you to join us in room 203 at the Openstack conference. We will be working through the following: https://etherpad.openstack.org/p/juno-design-summit-designate-session-3 Cheers, joe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [desigante] meeting in room 203 for more design work
Hello all, If you are still at the conference today (May 14), we invite you to join us in room 203 at the Openstack conference. We will be working through the following: https://etherpad.openstack.org/p/juno-design-summit-designate-session-3 Cheers, joe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Have you found that #openstack-neutron is too busy for LBaaS discussions? The downside to moving LBaaS discussions to a separate channel from the general neutron channel is that many neutron developers are left out of the discussion. -- Kevin Benton On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.com wrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [HEAT] Discussion: How to list nested stack resources.
Hi All, I recently tried to create a nested stack with the following example : http://paste.openstack.org/show/79156/ heat resource-list gives only MyStack but intention should be to list all the resources created by the nested templates, as also pointed by the command help: resource-list Show list of resources belonging to a stack Let me know if this requires a BP to be created for discussion. Thanks. -- Nilakhya | Consultant Engineering GlobalLogic P +x.xxx.xxx. M +91.989.112.5770 S skype www.globallogic.com http://www.globallogic.com/ http://www.globallogic.com/email_disclaimer.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Will this be recorded? or can I join webex? Thank You, Punal Patel On Wed, May 14, 2014 at 10:06 AM, Chris Wright chr...@redhat.com wrote: Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
At Wed, 14 May 2014 14:40:03 -0700, punal patel wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Will this be recorded? or can I join webex? There's no official recording facility. You may be able to ask someone to record or stream. BTW, I think it is a good idea to try to take discussion memo on etherpad, just as official design summit programs. On Wed, May 14, 2014 at 10:06 AM, Chris Wright chr...@redhat.com wrote: Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1.2 text/html; UTF-8 (quoted-printable)] [2 text/plain; us-ascii (7bit)] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor
Hello! This is very an interesting topic! I would like to talk about one idea I had, which is related to: 1.9. API for VPN. I think it would be awesome, for example, when dealing with IPv6-Only Projects (Tenants) Networks, the VPNs should use `Opportunistic Encryption`, this way, the VPNs will be established by default without any user interaction. Then, IPSec VPN for `IPv6 - IPv6` subnets will be always there, safely interconnecting the subnets, everywhere, even across different Regions or across different Projects (old Tenants terminology). I already started a topic about this but, I'm a bit busy these days... I'll reply there and I'm drawing a blueprint for it... Best! Thiago On 14 May 2014 12:16, Tina TSOU tina.tsou.zout...@huawei.com wrote: Dear all, Below is the main conclusion from this meeting. We will work on the following SDN NBI Core APIs at the priority per Neutron's interest. 2, 7, 10, 9, 11. 1.2 APIs for connection between OpenStack Neutron and controller OpenStack is widely used and deployed in cloud scenarios.OpenStack-based data center is becoming mainstream. There should be APIs for connection between SDN controller and OpenStack Neutron. 1.7 APIs for Virtual-Tenant-Network (VTN) VTN allows users and developers to design and deploy virtual networks without the need to know the physical network. This is very useful in data center. There should be APIs for virtual tenant network. 1.10 APIs for QoS QoS is usually for end user application. For example, the UC-SDN-Use-Case needs the network to guarantee its flow QoS to improve the user’s QoE. There should be APIs for QoS. 1.9 APIs for VPN VPN is also widely use in enterprise network, interconnectionbetween data centers and mobile environments. The management and operation of VPN are necessary. There should be APIs for VPN. The VPN may include the following type L2 VPN L3 VPN 1.11 APIs for network stats/state The network stats/state is needed by application so that the application can react with the corresponding policy. There should be APIs for network stats/state. Thank you, Tina On May 14, 2014, at 10:00 AM, Tina TSOU tina.tsou.zout...@huawei.com wrote: Dear all, Place is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area. Thank you, Tina On May 13, 2014, at 10:00 PM, Tina TSOU tina.tsou.zout...@huawei.com wrote: Dear Stackers, We are setting up a meeting to SDN NBI Core APIs consumed by OpenStack. Attached is the material for your reading pleasure. The meeting is planned for: *Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor .* Look forward to meeting many of you then. Thank you, Tina NBI Core APIs.docx ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Stephen, One nit and one question - For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models. - How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc. Best, Craig On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.netwrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Can't wait :-). On 14 May 2014 19:06, Chris Wright chr...@redhat.com wrote: Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Craig, I was attempting to avoid haproxy-specific terminology here, but some of those attributes are on the listener (ie. keepalive = 0 would be equivalent to httpclose). Other options (like adding headers) are expressed through the layer-7 functionality. So, we have yet to update the API to correspond with this object diagram, but if you recall the API I linked on the list a couple weeks ago ( https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing) look in the section on L7 policies and L7 rules. (Note also that we don't yet have group consensus on the specifics of implementing the L7 stuff-- but adding headers would definitely fall in that category, eh.) Stephen On Wed, May 14, 2014 at 3:04 PM, Craig Tracey cr...@craigtracey.com wrote: Thanks Stephen, One nit and one question - For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models. - How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc. Best, Craig On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
At Wed, 14 May 2014 10:18:29 -0700, Stephen Balukoff wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Sorry for jumping into a meta-argument, but what the LBaaS community needs to do first is to figure out how to make the neutron community agree on a LBaaS proposal. On the other hand, the neutron community (or the core?) needs to make it clear that what criteria or process is required to approve some LBaaS idea (obj. model, API, whatsoever). I'm sorry to say (again) that not much people have energy to follow and check out small differences in those large pictures of LBaaS object models. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
# heat stack-create -f example.yaml # heat stack-list Assume the stack id is: 5d44526e-e75c-4cec-aeea-252d6d15254b # heat resource-list 5d44526e-e75c-4cec-aeea-252d6d15254b You get the resource named 'MyStack'. To check the details: # heat resource-show 5d44526e-e75c-4cec-aeea-252d6d15254b MyStack You now get the physical_resource_id for MyStack. Let's assume it to be: 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 # heat resource-list 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 Now you get your resource whose type is 'file:////heat.yaml'. Its name could be a random string. You can check that resource using: # heat resource-show 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 name The process is a little bit dirty, though doable. If you want to submit a blueprint on this, it would be desirable to have it generic enough to cover all nested stack cases. Regards, - Qiming On Thu, May 15, 2014 at 03:02:00AM +0530, Nilakhya Chatterjee wrote: Hi All, I recently tried to create a nested stack with the following example : http://paste.openstack.org/show/79156/ heat resource-list gives only MyStack but intention should be to list all the resources created by the nested templates, as also pointed by the command help: resource-list Show list of resources belonging to a stack Let me know if this requires a BP to be created for discussion. Thanks. -- Nilakhya | Consultant Engineering GlobalLogic P +x.xxx.xxx. M +91.989.112.5770 S skype www.globallogic.com http://www.globallogic.com/ http://www.globallogic.com/email_disclaimer.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
11 people have responded so far. Please note that tomorrow is the last day to do the survey. I will close the survey and publish the results sometimes tomorrow night. Regards, -Sam. On 9 במאי 2014, at 15:59, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Sam, That deadline seems reasonable to me. I should have time later today or later this weekend to fill it out. Thanks, Stephen On Fri, May 9, 2014 at 9:21 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, 9 people have filled the survey so far. See attached pdf. Regards, -Sam. From: Samuel Bercovici Sent: Thursday, May 08, 2014 2:51 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey Hi everyone, I think that it is a good feedback to prioritize features. I can publish the results in time for the 2nd LBaaS meeting (so deadline would be end of 15th May “summit time”) Is this acceptable? -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, May 08, 2014 2:17 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey Hi Samuel-- I've been heads down working on API proposal review documentation, and haven't had time to fill it out yet. Do you have a deadline by which we should have filled out the survey to get our voices heard? Thanks, Stephen On Wed, May 7, 2014 at 2:16 PM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: 6 people have completed the survey so far. From: Samuel Bercovici Sent: Tuesday, May 06, 2014 10:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey Hi Everyone, The survey is now live via: http://eSurv.org?u=lbaas_project_user The password is: lbaas The survey includes all the tenant facing use cases from https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing Please try and fill the survey this week so we can have enough information to base decisions next week. Regards, -Sam. From: Samuel Bercovici Sent: Monday, May 05, 2014 4:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey Hi, I will not freeze the document to allow people to work on requirements which are not tenant facing (ex: operator, etc.) I think that we have enough use cases for tenant facing capabilities to reflect most common use cases. I am in the process of creation a survey in surveymonkey for tenant facing use cases and hope to send it to ML ASAP. Regards, -Sam. From: Samuel Bercovici Sent: Thursday, May 01, 2014 8:40 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Samuel Bercovici Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey Hi Everyone! To assist in evaluating the use cases that matter and since we now have ~45 use cases, I would like to propose to conduct a survey using something like surveymonkey. The idea is to have a non-anonymous survey listing the use cases and ask you identify and vote. Then we will publish the results and can prioritize based on this. To do so in a timely manner, I would like to freeze the document for editing and allow only comments by Monday May 5th 08:00AMUTC and publish the survey link to ML ASAP after that. Please let me know if this is acceptable. Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807tel:%28800%29613-4305%20x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
I'm planning to go to the neutron policy session at 1:30 but I'd like to find a chance to meet you and say hi. I'll be at the summit through Friday. Original message From: Luke Gorrie l...@tail-f.com Date: To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Ian Wells (iawells) iawe...@cisco.com Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit Can't wait :-). On 14 May 2014 19:06, Chris Wright chr...@redhat.com wrote: Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM
I'm sorry, you meant May 15, right? What is the neutron POD? Best regards, Max Lobur, Python Developer, Mirantis, Inc. Mobile: +38 (093) 665 14 28 Skype: max_lobur 38, Lenina ave. Kharkov, Ukraine www.mirantis.com www.mirantis.ru On Wed, May 14, 2014 at 8:06 PM, Justin Hammond justin.hamm...@rackspace.com wrote: Signed up for 11:30 AM, May 14 at the neutron POD. On 5/14/14 12:29 PM, Justin Hammond justin.hamm...@rackspace.com wrote: John Voss and I believe Thursday (May 15) would be the best time to do this. I will write it on the board. On 5/14/14 11:59 AM, Justin Hammond justin.hamm...@rackspace.com wrote: I also intend on advertising this during the core-refactoring session in the etherpad. Please pay attention to that if you're there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM
Yes sorry. May 15. The neutron pod is on level 2. You can get to it from level 3 if you go into the developer lounge, go down the spiral staircase surrounded by the curtains, then hang a slight right. I believe it is room 204? It says 'neutron' on the list of PODs. From: Maksym Lobur mlo...@mirantis.commailto:mlo...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thu, 15 May 2014 06:02:15 +0300 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Meet up time at the summit for a POD; Re: Pluggable IPAM I'm sorry, you meant May 15, right? What is the neutron POD? Best regards, Max Lobur, Python Developer, Mirantis, Inc. Mobile: +38 (093) 665 14 28 Skype: max_lobur 38, Lenina ave. Kharkov, Ukraine www.mirantis.comhttp://www.mirantis.com www.mirantis.ruhttp://www.mirantis.ru On Wed, May 14, 2014 at 8:06 PM, Justin Hammond justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote: Signed up for 11:30 AM, May 14 at the neutron POD. On 5/14/14 12:29 PM, Justin Hammond justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote: John Voss and I believe Thursday (May 15) would be the best time to do this. I will write it on the board. On 5/14/14 11:59 AM, Justin Hammond justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote: I also intend on advertising this during the core-refactoring session in the etherpad. Please pay attention to that if you're there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican] any barbican devs at summit?
Would be interested in syncing up to hear about your experiences with this. Anybody at the summit this week that'd be willing to chat for a few minutes? Email works to reach out to me, or I'm on IRC (mdorman) sporadically this week. Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad
Hi Everyone, https://etherpad.openstack.org/p/juno-lbaas-design-session Feel free to modify and update, please make sure you use your name so we will know who have added the modification. Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] any barbican devs at summit?
Hi Michael, There’s quite a few Barbican devs here at the summit. We’ll be hanging out at the Barbican table in room B204 tomorrow if you want to drop in and chat. You can also ping us on #openstack-barbican on freenode. - Douglas Mendizábal IRC: redrobot From: Michael Dorman mdor...@godaddy.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, May 14, 2014 at 8:54 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] any barbican devs at summit? Would be interested in syncing up to hear about your experiences with this. Anybody at the summit this week that’d be willing to chat for a few minutes? Email works to reach out to me, or I’m on IRC (mdorman) sporadically this week. Thanks, Mike smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad
Hi, I see the following statement in the doc. multiple loadbalancers may referenece the same listener Does this mean listeners are independent of loadbalancer? Thanks, Vijay V. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Thursday, May 15, 2014 9:26 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad Hi Everyone, https://etherpad.openstack.org/p/juno-lbaas-design-session Feel free to modify and update, please make sure you use your name so we will know who have added the modification. Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad
Hi, If a tenant wishes to expose his application (listener, pool(s), etc.) via multiple different virtual IP addresses you can do so. -Sam. From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Thursday, May 15, 2014 12:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad Hi, I see the following statement in the doc. multiple loadbalancers may referenece the same listener Does this mean listeners are independent of loadbalancer? Thanks, Vijay V. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Thursday, May 15, 2014 9:26 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]LBaaS 1st Session etherpad Hi Everyone, https://etherpad.openstack.org/p/juno-lbaas-design-session Feel free to modify and update, please make sure you use your name so we will know who have added the modification. Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
