<div>Hi <span style="line-height: 1.5;">Clayton,</span></div><div><span style="line-height: 1.5;">Thank you for your reply.</span></div><div>Recently our team used a VM as LVS, the rule in iptables will DROP the invalid message which makes the LVS could not work successfully.</div><div>So we want to use security-port to complete it. The API requirement is not clear.</div><div>And BTW, dose icehouse support security-port?</div><div><br></div><div>Thanks.</div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "openstack-operators-request";<openstack-operators-request@lists.openstack.org>;</div><div><b>Date: </b> Wed, Jul 15, 2015 05:41 PM</div><div><b>To: </b> "openstack-operators"<openstack-operators@lists.openstack.org>; <wbr></div><div></div><div><b>Subject: </b> OpenStack-operators Digest, Vol 57, Issue 19</div></div><div><br></div>Send OpenStack-operators mailing list submissions to<br>        openstack-operators@lists.openstack.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br>or, via email, send a message with subject or body 'help' to<br>       openstack-operators-request@lists.openstack.org<br><br>You can reach the person managing the list at<br>      openstack-operators-owner@lists.openstack.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of OpenStack-operators digest..."<br><br><br>Today's Topics:<br><br>   1. Re: How to configure security-port feature in Kilo ?<br>      (Clayton O'Neill)<br>   2. Ceilometer client uses the wrong URL when  contacting service<br>      (Alvise Dorigo)<br>   3. Re: OSAD for RHEL (Adam Young)<br>   4. Meeting Thursday July 16th at 17:00UTC (Christopher Aedo)<br>   5. [app-catalog] IRC Meeting Thursday July 16th     at 17:00UTC<br>      (Christopher Aedo)<br>   6. Re: OSAD for RHEL (Kevin Carter)<br>   7. [Neutron] New etherpad for collecting Neutron instrumentation<br>      requirements (Ryan Moats)<br>   8. Re: [openstack-dev] [Openstack] Rescinding   the M name<br>      decision (Lauren Sell)<br>   9. Re: OSAD for RHEL (Kevin Carter)<br>  10. Re: FAiled to create instance wiht openstack nova network<br>      (pra devOPS)<br>  11. Re: Scaling the Ops Meetup (Tom Fifield)<br>  12. Neutron LBaaS HA in KIlo? (Pedro Sousa)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Tue, 14 Jul 2015 08:28:59 -0500<br>From: "Clayton O'Neill" <clayton@oneill.net><br>To: openstack-operators <openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] How to configure security-port<br>    feature in Kilo ?<br>Message-ID:<br>        <CADg-rOX0yYprWM1DSfnP4yt8Vg48OBxV2zagrNBck1tL1M7Frw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Note that if you enable port-security when you upgrade to kilo you can<br>avoid these issues.  If you enable port-security after upgrading, it's a<br>few pretty simple SQL commands to work around the bug below? described<br>below.  You can find them in the associated kilo upgrade db migration here:<br><br>https://github.com/openstack/neutron/blob/master/neutron/db/migration/alembic_migrations/versions/35a0f3365720_add_port_security_in_ml2.py<br><br>That said, I'd be glad to hear more about how to actually *use* the port<br>security extension.  It seems as if it can be used to turn off port<br>security on a per port or per network basis.  Is there any UI for this, or<br>do you have to use the API?<br><br>On Tue, Jul 14, 2015 at 5:52 AM, James Denton <james.denton@rackspace.com><br>wrote:<br><br>>  In the /etc/neutron/plugins/ml2/ml2_conf.ini file, add the following<br>> under [ml2] and restart the neutron-server service:<br>><br>><br>>  extension_drivers = port_security<br>><br>><br>>  You may experience the following bugs upon enabling port security:<br>><br>><br>>  https://bugs.launchpad.net/neutron/+bug/1461519<br>><br>> https://bugs.launchpad.net/neutron/+bug/1454148?<br>><br>><br>>  If you can, remove all existing Neutron networks prior to enabling port<br>> security. Otherwise, you may be looking at some DB changes to get things<br>> working again.<br>><br>><br>>  James<br>>  ------------------------------<br>> *From:* 16189455@qq.com <16189455@qq.com><br>> *Sent:* Tuesday, July 14, 2015 12:17 AM<br>> *To:* openstack-operators<br>> *Subject:* [Openstack-operators] How to configure security-port feature<br>> in Kilo ?<br>><br>>  Hi all,<br>>     Recently I want to have a try of the  feature security-port, but these<br>> is very few introduction. Could you give some help?<br>>     Thank you.<br>><br>><br>><br>> _______________________________________________<br>> OpenStack-operators mailing list<br>> OpenStack-operators@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/b1448315/attachment-0001.html><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 14 Jul 2015 16:38:02 +0200<br>From: Alvise Dorigo <alvise.dorigo@pd.infn.it><br>To: "openstack-operators@lists.openstack.org"<br>     <openstack-operators@lists.openstack.org><br>Subject: [Openstack-operators] Ceilometer client uses the wrong URL<br>  when    contacting service<br>Message-ID: <55A51ECA.3090204@pd.infn.it><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Hi,<br>I've setup an OpenStack IceHouse deployment with SSL.<br><br>The Ceilometer service is registered in Keystone with the https endpoints:<br><br>[root@controller-01 ~]# keystone endpoint-list|grep 8777<br>| 8c12e36a75454c5da92ac146630a7022 | regionOne | <br>https://cloud-areapd-test.pd.infn.it:8777          | <br>https://cloud-areapd-test.pd.infn.it:8777          | <br>https://cloud-areapd-test.pd.infn.it:8777          | <br>8f765dc84a884786b0e95076a20f1c4c |<br><br>When I select on the dashboard the menu "Resource usage", it hungs, and <br>in the horizon.log file I see this error:<br><br>2015-07-14 14:27:03,899 9751 DEBUG ceilometerclient.common.http curl -i <br>-X GET -H 'X-Auth-Token: 46778be5fbe2c753766b501314e6effa' -H <br>'Content-Type: application/json' -H 'Accept: application/json' -H <br>'User-Agent: python-ceilometerclient' http://90.147.77.250:8777/v2/meters<br><br><br>Why ( and from where) the ceilometerclient is getting the wrong non-SSL <br>endpoint http://90.147.77.250:8777/v2/meters ?<br>I thought it would take that URL from the Keystone's endpoint catalog <br>(which contains the correct https URLs); but it seems that it is not true.<br><br>Could someone explain and help me to set it up correctly ?<br><br>thanks,<br><br>     Alvise<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 14 Jul 2015 11:59:20 -0400<br>From: Adam Young <ayoung@redhat.com><br>To: Kevin Carter <kevin.carter@rackspace.com>, "Kris G. Lindgren"<br>    <klindgren@godaddy.com>, John Dewey <john@dewey.ws><br>Cc: "openstack-operators@lists.openstack.org"<br>      <openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br>Message-ID: <55A531D8.2040507@redhat.com><br>Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br><br>On 07/10/2015 02:25 PM, Kevin Carter wrote:<br>><br>> To be clear the present OSAD project really has no intention to bring <br>> package based installations of OpenStack. We'd certainly not reject <br>> the idea and wouldn't mind having an implementation spec for it <br>> but all of our current tooling and design principles have been based <br>> on the fact that we've move away from distro packages and on to <br>> upstream source as it pertains to OpenStack. The system as it stands <br>> today creates an internal repository of built wheels for your <br>> environment and all of the OpenStack services are installed within LXC <br>> containers, where possible and it makes sense. The installation of <br>> these bits comes from the internal wheel repository and uses pip and <br>> all of the pre / post config happens within the Ansible playbooks.<br>><br><br>I understand your frustration with the packaging approach.  For a first <br>approximation, getting the code for OpenStack/Python operations out of <br>Pip makes sense.  Ideally, we would be able to support both approaches.  <br>Red Hat would not support a pip based install, but I am sure some Centos <br>base users would be happy with pip.<br><br>We had the same general discussion around devstack.<br><br>><br>> One issue that will become a problem, for users of RedHat <br>> specifically, is the fact that RedHat has no LXC container templates <br>> (at least none that are publicly available) and even if someone were <br>> to make an official RedHat container template there'd be issues with <br>> the containers being able to connect to the satellite servers as well <br>> as other potential license problems.<br>><br><br>I'd leave the issues with getting blessed RHEL LXC support to Red Hat.  <br>Making something that works for CentOS with publically available LXC <br>containers there would be more what I expect from OSAD upstream.<br><br>What about Fedora support?  It seems to me that we would be far more <br>likely to have something supportable with Fedora that could then be <br>backported to CentOS?<br><br>><br>> I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 <br>> containers and things seem to work OK but I'd not say that I have <br>> really put a lot of effort into it. That said, if its something that <br>> you'd all like to work on I'd be happy to help out to make it all go.<br>><br><br>Sounds good.  I'll give it a try after the Keystone Midcycle.<br><br>><br>> --<br>><br>> Kevin Carter<br>> ------------------------------------------------------------------------<br>> *From:* Adam Young <ayoung@redhat.com><br>> *Sent:* Thursday, July 9, 2015 11:32 AM<br>> *To:* Kris G. Lindgren; John Dewey<br>> *Cc:* openstack-operators@lists.openstack.org<br>> *Subject:* Re: [Openstack-operators] OSAD for RHEL<br>> On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:<br>>> Does OSP support running each service in an LXC container as well? <br>>>  What about nova-cells? How does it handle people who need to carry <br>>> local changes?  What is the upgrade path like with OSP?<br>><br>> So, ignoring the Hypervisor for the moment, there is no reason that <br>> the rest of the controllers can't run in separate Containers.  I think <br>> a container based deployment would be fantastic.<br>><br>> venv is not really sufficient, as the system level binaries can still <br>> conflict (MysQL and LDAP both require system libraries for Keystone, <br>> for example)<br>><br>> From an Ansible perspective;  we need to  be able to share the HTTPD <br>> instance for Keystone and Apache, and getting that right will solve <br>> most of the issues deploying in a secure manner. Putting Them on <br>> separate hosts or containers should be a degenerate case, and thus be <br>> supported, too.<br>><br>><br>><br>><br>><br>><br>>><br>>> Asking, because in Philly the general consensus, I fel,t was people <br>>> want to move away from the current system level package stuff and <br>>> move towards: venv's, "lightweight packages", containers.  The only <br>>> reason that was brought up to keep packages around was to solve the <br>>> non-python lib stuff and using a depsolver (yum/apt) that doesn't <br>>> suck (pip).  So I am pretty sure my wants are inline with what other <br>>> people in the community are either already doing or moving towards.<br>>> ___________________________________________<br>>> Kris Lindgren<br>>> Senior Linux Systems Engineer<br>>> GoDaddy, LLC.<br>>><br>>><br>>> From: John Dewey <john@dewey.ws <mailto:john@dewey.ws>><br>>> Date: Wednesday, July 8, 2015 at 11:43 PM<br>>> To: "Kris G. Lindgren" <klindgren@godaddy.com <br>>> <mailto:klindgren@godaddy.com>><br>>> Cc: Adam Young <ayoung@redhat.com <mailto:ayoung@redhat.com>>, <br>>> "openstack-operators@lists.openstack.org <br>>> <mailto:openstack-operators@lists.openstack.org>" <br>>> <openstack-operators@lists.openstack.org <br>>> <mailto:openstack-operators@lists.openstack.org>><br>>> Subject: Re: [Openstack-operators] OSAD for RHEL<br>>><br>>> This would not be acceptable for those running OSP.<br>>><br>>> On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote:<br>>><br>>>> I should be more clear. My current thought is to have a venv packaged<br>>>> inside an rpm - so the rpm includes the needed init scripts, ensures the<br>>>> required system level binaries are installed, adds the users - ect ect.<br>>>> But would be a single deployable autonomous unit. Also, have a <br>>>> versioning<br>>>> schema to roll forward and back between venvs for quick update/rollback.<br>>>> We are already working on doing something similar to this to run kilo on<br>>>> cent6 boxen, until we can finish revving the remaining parts of the <br>>>> fleet<br>>>> to cent7.<br>>>><br>>>> My desire is to move away from using system level python & openstack<br>>>> packages, so that I can possibly run mismatched versions if I need <br>>>> to. We<br>>>> had a need to run kilo ceilometer and juno neutron/nova on a single<br>>>> server. The conflicting python requirements between those made that task<br>>>> impossible. In general I want to get away from treating Openstack as a<br>>>> single system that everything needs to be upgraded in lock step <br>>>> (packages<br>>>> force you into this). I want to move to being able to upgrade say<br>>>> oslo.messaging to a newer version on just say nova on my control plane<br>>>> servers. Or upgrade nova to kilo while keeping the rest of the system<br>>>> (neutron) on juno. Unless I run each service in a vm/container or on a<br>>>> physical piece of hardware that is pretty much impossible to do with<br>>>> packages - outside of placing everything inside venv's.<br>>>><br>>>> However, it is my understanding that OSAD already builds its own<br>>>> python-wheels and runs those inside lxc containers. So I don?t really<br>>>> follow what good throwing those into an rpm would really do?<br>>>> ____________________________________________<br>>>> Kris Lindgren<br>>>> Senior Linux Systems Engineer<br>>>> GoDaddy, LLC.<br>>>><br>>>><br>>>> On 7/8/15, 10:33 PM, "Adam Young" <ayoung@redhat.com <br>>>> <mailto:ayoung@redhat.com>> wrote:<br>>>><br>>>>> On 07/07/2015 05:55 PM, Kris G. Lindgren wrote:<br>>>>>> +1 on RHEL support. I have some interest in moving away from packages<br>>>>>> and<br>>>>>> am interested in the OSAD tooling as well.<br>>>>><br>>>>> I would not recommend an approach targetting RHEL that does not use<br>>>>> packages.<br>>>>><br>>>>> OSAD support for RHEL using packages would be an outstanding tool.<br>>>>><br>>>>> Which way are you planning on taking it?<br>>>>><br>>>>>> ____________________________________________<br>>>>>> Kris Lindgren<br>>>>>> Senior Linux Systems Engineer<br>>>>>> GoDaddy, LLC.<br>>>>>><br>>>>>><br>>>>>><br>>>>>><br>>>>>><br>>>>>><br>>>>>><br>>>>>> On 7/7/15, 3:38 PM, "Abel Lopez" <alopgeek@gmail.com <br>>>>>> <mailto:alopgeek@gmail.com>> wrote:<br>>>>>><br>>>>>>> Hey everyone,<br>>>>>>> I've started looking at osad, and I like much of the direction it<br>>>>>>> takes.<br>>>>>>> I'm pretty interested in developing it to run on RHEL, I just <br>>>>>>> wanted to<br>>>>>>> check if anyone would be -2 opposed to that before I spend cycles on<br>>>>>>> it.<br>>>>>><br>>>>>> _______________________________________________<br>>>>>> OpenStack-operators mailing list<br>>>>>> OpenStack-operators@lists.openstack.org <br>>>>>> <mailto:OpenStack-operators@lists.openstack.org><br>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>>>>><br>>>>><br>>>>> _______________________________________________<br>>>>> OpenStack-operators mailing list<br>>>>> OpenStack-operators@lists.openstack.org <br>>>>> <mailto:OpenStack-operators@lists.openstack.org><br>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>>>><br>>>><br>>>> _______________________________________________<br>>>> OpenStack-operators mailing list<br>>>> OpenStack-operators@lists.openstack.org <br>>>> <mailto:OpenStack-operators@lists.openstack.org><br>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>>><br>><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/1d20fa1f/attachment-0001.html><br><br>------------------------------<br><br>Message: 4<br>Date: Tue, 14 Jul 2015 10:02:36 -0700<br>From: Christopher Aedo <doc@aedo.net><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>    <openstack-dev@lists.openstack.org>,<br>    openstack-operators@lists.openstack.org<br>Subject: [Openstack-operators] Meeting Thursday July 16th at 17:00UTC<br>Message-ID:<br>   <CA+odVQG4TCuh0i29n6gotiRFeQquDG1kWk9ezVf73ROj4jE9+Q@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Hello! Our next OpenStack App Catalog meeting will take place this<br>Thursday July 16th at 17:00 UTC in #openstack-meeting-3<br><br>The agenda can be found here:<br>https://wiki.openstack.org/wiki/Meetings/app-catalog<br><br>Please add agenda items if there's anything specific you would like to<br>discuss.  For this weeks meeting my primary intention is to discuss<br>the roadmap, everything we'd like to accomplish before the next<br>summit, and determine who all will be helping get it done.<br><br>Please join us if you can!<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Tue, 14 Jul 2015 10:14:40 -0700<br>From: Christopher Aedo <doc@aedo.net><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>        <openstack-dev@lists.openstack.org>,<br>    openstack-operators@lists.openstack.org<br>Subject: [Openstack-operators] [app-catalog] IRC Meeting Thursday July<br>       16th    at 17:00UTC<br>Message-ID:<br>      <CA+odVQG0afWBs6=0L1QQqnsnSDzpmk2c3z9g_VdiQPdr_1J1kQ@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>(Apologies for the re-send, missed the appropriate tag on the subject line!)<br><br>Hello! Our next OpenStack App Catalog meeting will take place this<br>Thursday July 16th at 17:00 UTC in #openstack-meeting-3<br><br>The agenda can be found here:<br>https://wiki.openstack.org/wiki/Meetings/app-catalog<br><br>Please add agenda items if there's anything specific you would like to<br>discuss.  For this weeks meeting my primary intention is to discuss<br>the roadmap, everything we'd like to accomplish before the next<br>summit, and determine who all will be helping get it done.<br><br>Please join us if you can!<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Tue, 14 Jul 2015 18:41:21 +0000<br>From: Kevin Carter <kevin.carter@RACKSPACE.COM><br>To: Adam Young <ayoung@redhat.com>, "Kris G. Lindgren"<br>    <klindgren@godaddy.com>, John Dewey <john@dewey.ws><br>Cc: "openstack-operators@lists.openstack.org"<br>      <openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br>Message-ID: <1436899281115.85866@RACKSPACE.COM><br>Content-Type: text/plain; charset="utf-8"<br><br>?<br><br><br>--<br><br>Kevin Carter<br>Racker, Developer, Hacker @ The Rackspace Private Cloud.<br>________________________________<br>From: Adam Young <ayoung@redhat.com><br>Sent: Tuesday, July 14, 2015 10:59 AM<br>To: Kevin Carter; Kris G. Lindgren; John Dewey<br>Cc: openstack-operators@lists.openstack.org<br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>On 07/10/2015 02:25 PM, Kevin Carter wrote:<br><br>To be clear the present OSAD project really has no intention to bring package based installations of OpenStack. We'd certainly not reject the idea and wouldn't mind having an implementation spec for it but all of our current tooling and design principles have been based on the fact that we've move away from distro packages and on to upstream source as it pertains to OpenStack. The system as it stands today creates an internal repository of built wheels for your environment and all of the OpenStack services are installed within LXC containers, where possible and it makes sense. The installation of these bits comes from the internal wheel repository and uses pip and all of the pre / post config happens within the Ansible playbooks.<br><br>I understand your frustration with the packaging approach.  For a first approximation, getting the code for OpenStack/Python operations out of Pip makes sense.  Ideally, we would be able to support both approaches.  Red Hat would not support a pip based install, but I am sure some Centos base users would be happy with pip.<br><br>We had the same general discussion around devstack.<br><br><br><br>One issue that will become a problem, for users of RedHat specifically, is the fact that RedHat has no LXC container templates (at least none that are publicly available) and even if someone were to make an official RedHat container template there'd be issues with the containers being able to connect to the satellite servers as well as other potential license problems.<br><br>I'd leave the issues with getting blessed RHEL LXC support to Red Hat.  Making something that works for CentOS with publically available LXC containers there would be more what I expect from OSAD upstream.<br><br>What about Fedora support?  It seems to me that we would be far more likely to have something supportable with Fedora that could then be backported to CentOS?<br><br><br><br>I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers and things seem to work OK but I'd not say that I have really put a lot of effort into it. That said, if its something that you'd all like to work on I'd be happy to help out to make it all go.<br><br>Sounds good.  I'll give it a try after the Keystone Midcycle.<br><br><br><br>--<br><br>Kevin Carter<br>________________________________<br>From: Adam Young <ayoung@redhat.com><mailto:ayoung@redhat.com><br>Sent: Thursday, July 9, 2015 11:32 AM<br>To: Kris G. Lindgren; John Dewey<br>Cc: openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:<br>Does OSP support running each service in an LXC container as well?  What about nova-cells? How does it handle people who need to carry local changes?  What is the upgrade path like with OSP?<br><br>So, ignoring the Hypervisor for the moment, there is no reason that the rest of the controllers can't run in separate Containers.  I think a container based deployment would be fantastic.<br><br>venv is not really sufficient, as the system level binaries can still conflict (MysQL and LDAP both require system libraries for Keystone, for example)<br><br>From an Ansible perspective;  we need to  be able to share the HTTPD instance for Keystone and Apache, and getting that right will solve most of the issues deploying in a secure manner.  Putting Them on separate hosts or containers should be a degenerate case, and thus be supported, too.<br><br><br><br><br><br><br><br>Asking, because in Philly the general consensus, I fel,t was people want to move away from the current system level package stuff and move towards: venv's, "lightweight packages", containers.  The only reason that was brought up to keep packages around was to solve the non-python lib stuff and using a depsolver (yum/apt) that doesn't suck (pip).  So I am pretty sure my wants are inline with what other people in the community are either already doing or moving towards.<br>___________________________________________<br><br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br>From: John Dewey <john@dewey.ws<mailto:john@dewey.ws>><br>Date: Wednesday, July 8, 2015 at 11:43 PM<br>To: "Kris G. Lindgren" <klindgren@godaddy.com<mailto:klindgren@godaddy.com>><br>Cc: Adam Young <ayoung@redhat.com<mailto:ayoung@redhat.com>>, "openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>This would not be acceptable for those running OSP.<br><br><br>On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote:<br><br>I should be more clear. My current thought is to have a venv packaged<br>inside an rpm - so the rpm includes the needed init scripts, ensures the<br>required system level binaries are installed, adds the users - ect ect.<br>But would be a single deployable autonomous unit. Also, have a versioning<br>schema to roll forward and back between venvs for quick update/rollback.<br>We are already working on doing something similar to this to run kilo on<br>cent6 boxen, until we can finish revving the remaining parts of the fleet<br>to cent7.<br><br>My desire is to move away from using system level python & openstack<br>packages, so that I can possibly run mismatched versions if I need to. We<br>had a need to run kilo ceilometer and juno neutron/nova on a single<br>server. The conflicting python requirements between those made that task<br>impossible. In general I want to get away from treating Openstack as a<br>single system that everything needs to be upgraded in lock step (packages<br>force you into this). I want to move to being able to upgrade say<br>oslo.messaging to a newer version on just say nova on my control plane<br>servers. Or upgrade nova to kilo while keeping the rest of the system<br>(neutron) on juno. Unless I run each service in a vm/container or on a<br>physical piece of hardware that is pretty much impossible to do with<br>packages - outside of placing everything inside venv's.<br><br>However, it is my understanding that OSAD already builds its own<br>python-wheels and runs those inside lxc containers. So I don?t really<br>follow what good throwing those into an rpm would really do?<br>____________________________________________<br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br>On 7/8/15, 10:33 PM, "Adam Young" <ayoung@redhat.com<mailto:ayoung@redhat.com>> wrote:<br><br>On 07/07/2015 05:55 PM, Kris G. Lindgren wrote:<br>+1 on RHEL support. I have some interest in moving away from packages<br>and<br>am interested in the OSAD tooling as well.<br><br>I would not recommend an approach targetting RHEL that does not use<br>packages.<br><br>OSAD support for RHEL using packages would be an outstanding tool.<br><br>Which way are you planning on taking it?<br><br>____________________________________________<br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br><br><br><br><br><br>On 7/7/15, 3:38 PM, "Abel Lopez" <alopgeek@gmail.com<mailto:alopgeek@gmail.com>> wrote:<br><br>Hey everyone,<br>I've started looking at osad, and I like much of the direction it<br>takes.<br>I'm pretty interested in developing it to run on RHEL, I just wanted to<br>check if anyone would be -2 opposed to that before I spend cycles on<br>it.<br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/d00229cb/attachment-0001.html><br><br>------------------------------<br><br>Message: 7<br>Date: Tue, 14 Jul 2015 13:46:51 -0500<br>From: "Ryan Moats" <rmoats@us.ibm.com><br>To: openstack-operators@lists.openstack.org<br>Subject: [Openstack-operators] [Neutron] New etherpad for collecting<br>     Neutron instrumentation requirements<br>Message-ID: <201507141847.t6EIlrxh029018@d01av01.pok.ibm.com><br>Content-Type: text/plain; charset="us-ascii"<br><br><br><br>All-<br><br>There is an effort getting underway to generate an RFE (request for<br>enhancement), BPs and code changes to add instrumentation to neutron.  An<br>etherpad has been set up at<br>https://etherpad.openstack.org/p/neutron-instrumentation to collect the<br>type of information that would be useful to OpenStack operators.<br><br>Please visit the page and add items that your organization feels would be<br>useful to have instrumented in Neutron or +1 items that are already there.<br>Feel free to fill in information on parts II (What to do with this<br>instrumentation once we have it) and part III (How should Ceilometer talk<br>to legacy systems) as well...<br><br>Thanks in advance,<br>Ryan Moats<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/edcaf523/attachment-0001.html><br><br>------------------------------<br><br>Message: 8<br>Date: Tue, 14 Jul 2015 13:53:19 -0500<br>From: Lauren Sell <lauren@openstack.org><br>To: "OpenStack Development Mailing List (not for usage questions)"<br>     <openstack-dev@lists.openstack.org><br>Cc: "openstack-operators@lists.openstack.org"<br>    <openstack-operators@lists.openstack.org>,<br>      "openstack@lists.openstack.org" <openstack@lists.openstack.org>,<br>      "Jonathan Bryce \(jonathan@openstack.org\)" <jonathan@openstack.org><br>Subject: Re: [Openstack-operators] [openstack-dev] [Openstack]<br>  Rescinding      the M name decision<br>Message-ID: <93B396BC-E9FC-443C-8E9D-D13B26B50BAC@openstack.org><br>Content-Type: text/plain; charset=utf-8<br><br>Good news. After finalizing the trademark checks and giving the community time to weigh in, Mitaka will be the name of the M release. <br><br>Thanks again for the great discussion around this topic, and for the willingness to be responsive to the concerns of fellow community members.<br><br><br>> On Jul 9, 2015, at 2:18 PM, Tim Bell <Tim.Bell@cern.ch> wrote:<br>> <br>> Feel free to give input on the Mitaka proposal.<br>> <br>> Tim<br>> <br>>> -----Original Message-----<br>>> From: Jonathan Bryce [mailto:jbryce@jbryce.com]<br>>> Sent: 09 July 2015 20:52<br>>> To: OpenStack Development Mailing List (not for usage questions)<br>>> Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision<br>>> <br>>>> On Jul 9, 2015, at 9:35 AM, Russell Bryant <rbryant@redhat.com> wrote:<br>>>> <br>>>> On 07/09/2015 09:19 AM, Neil Jerram wrote:<br>>>>> In the hope of forestalling an unnecessary sub-thread...<br>>>>> <br>>>>> Mita was #1 in the vote, so has presumably already been ruled out by<br>>>>> OpenStack's legal review.<br>>>> <br>>>> That is correct.<br>>> <br>>> <br>>> Hi everyone,<br>>> <br>>> I?ve really loved seeing everyone?s understanding and engagement on this<br>>> thread as we worked through the release cycle naming for ?M?. This was the<br>>> first attempt to follow a new process, so not surprisingly, we found some<br>>> improvements in the algorithm for the future. Still it?s awesome to see how<br>>> constructive and positive the whole conversation has been.<br>>> <br>>> I wanted to provide a quick update on the status of the Foundation?s<br>>> reviews of the names. First, as Russell mentioned above, after the voting<br>>> was completed, we asked our trademark counsel to do checks on the top 3<br>>> names. The first two both had significant trademark issues with existing<br>>> trademark holders in the same space that would have prevented us from<br>>> using the names in most jurisdictions where we have our largest<br>>> communities (US, Europe and Asia). The 3rd choice was relatively low risk<br>>> and so we passed word back to Monty who announced it. Once we realized<br>>> there were other issues with Meiji, we asked for an expedited check of the<br>>> next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows<br>>> that Mitaka and Meguro both present an acceptable level of risk, while<br>>> Musashi is higher on the risk scale and would probably create problems for<br>>> usage.<br>>> <br>>> At this time, we?re going to do a deeper check on Mitaka, which was the #4<br>>> candidate in voting and would be next in line after Meiji. I know Itoh-san<br>>> mentioned the Mitaka locale has the potential to be associated with certain<br>>> corporations in Japan, but my personal feeling is that may not be significant<br>>> enough to override it?s position in the voting and it?s availability for use.<br>>> <br>>> I?d encourage anyone with other concerns about Mitaka to post those<br>>> within the next 24 hours so we can appropriately consider and discuss<br>>> them. We should have results on the deeper trademark check by next week<br>>> as well and can hopefully settle on a final name.<br>>> <br>>> Thanks again for all the discussion and participation and especially to<br>>> Monty who?s been on the front lines of helping us navigate this. Feel free to<br>>> let me know if you have any other questions,<br>>> <br>>> Jonathan<br>>> 210-317-2438<br>>> <br>>> <br>>> __________________________________________________________<br>>> ________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-<br>>> request@lists.openstack.org?subject:unsubscribe<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Tue, 14 Jul 2015 19:01:41 +0000<br>From: Kevin Carter <kevin.carter@RACKSPACE.COM><br>To: Adam Young <ayoung@redhat.com>, "Kris G. Lindgren"<br>   <klindgren@godaddy.com>, John Dewey <john@dewey.ws><br>Cc: "openstack-operators@lists.openstack.org"<br>      <openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br>Message-ID: <1436900500710.26115@RACKSPACE.COM><br>Content-Type: text/plain; charset="utf-8"<br><br>?Sorry for the blank reply, hot keys got the better of me :)<br><br><br>@Adam<br><br><br>Are there any plans to create a publicly available LXC template that we could used by others and when you say "I'd leave the issues with getting blessed RHEL LXC support to Red Hat?" do you imaging RedHat providing images/templates to deployers wanting to deploy on RHEL??<br><br><br>I noticed that the LXC tooling that RedHat provides is old and while functional its not using the lxc python 3 clients or libraries. Are there any plans to repack LXC using the available py3m packages that are in RHEL7.1?<br><br>In terms of pip vs rpm/deb packages are there things that RedHat will not specifically support when using pip? Is it that any use of pip would invalidate general RHEL host support? I ask because we already have all of the tooling to support a source based deployment which has the ability to do rolling upgrades and while I've only experimented with adding RedHat as base host OS (tested using RHEL 7/7.1) it shouldn't be a huge forklift to get that work done though adding in distinct code paths for deployments powered by packages would be a lot more work. As for Fedora support, I dont think thats far off once we have a base RHEL/CentOS7 system running.<br><br>--<br><br>Kevin<br><br>________________________________<br>From: Adam Young <ayoung@redhat.com><br>Sent: Tuesday, July 14, 2015 10:59 AM<br>To: Kevin Carter; Kris G. Lindgren; John Dewey<br>Cc: openstack-operators@lists.openstack.org<br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>On 07/10/2015 02:25 PM, Kevin Carter wrote:<br><br>To be clear the present OSAD project really has no intention to bring package based installations of OpenStack. We'd certainly not reject the idea and wouldn't mind having an implementation spec for it but all of our current tooling and design principles have been based on the fact that we've move away from distro packages and on to upstream source as it pertains to OpenStack. The system as it stands today creates an internal repository of built wheels for your environment and all of the OpenStack services are installed within LXC containers, where possible and it makes sense. The installation of these bits comes from the internal wheel repository and uses pip and all of the pre / post config happens within the Ansible playbooks.<br><br>I understand your frustration with the packaging approach.  For a first approximation, getting the code for OpenStack/Python operations out of Pip makes sense.  Ideally, we would be able to support both approaches.  Red Hat would not support a pip based install, but I am sure some Centos base users would be happy with pip.<br><br>We had the same general discussion around devstack.<br><br><br><br>One issue that will become a problem, for users of RedHat specifically, is the fact that RedHat has no LXC container templates (at least none that are publicly available) and even if someone were to make an official RedHat container template there'd be issues with the containers being able to connect to the satellite servers as well as other potential license problems.<br><br>I'd leave the issues with getting blessed RHEL LXC support to Red Hat.  Making something that works for CentOS with publically available LXC containers there would be more what I expect from OSAD upstream.<br><br>What about Fedora support?  It seems to me that we would be far more likely to have something supportable with Fedora that could then be backported to CentOS?<br><br><br><br>I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers and things seem to work OK but I'd not say that I have really put a lot of effort into it. That said, if its something that you'd all like to work on I'd be happy to help out to make it all go.<br><br>Sounds good.  I'll give it a try after the Keystone Midcycle.<br><br><br><br>--<br><br>Kevin Carter<br>________________________________<br>From: Adam Young <ayoung@redhat.com><mailto:ayoung@redhat.com><br>Sent: Thursday, July 9, 2015 11:32 AM<br>To: Kris G. Lindgren; John Dewey<br>Cc: openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:<br>Does OSP support running each service in an LXC container as well?  What about nova-cells? How does it handle people who need to carry local changes?  What is the upgrade path like with OSP?<br><br>So, ignoring the Hypervisor for the moment, there is no reason that the rest of the controllers can't run in separate Containers.  I think a container based deployment would be fantastic.<br><br>venv is not really sufficient, as the system level binaries can still conflict (MysQL and LDAP both require system libraries for Keystone, for example)<br><br>From an Ansible perspective;  we need to  be able to share the HTTPD instance for Keystone and Apache, and getting that right will solve most of the issues deploying in a secure manner.  Putting Them on separate hosts or containers should be a degenerate case, and thus be supported, too.<br><br><br><br><br><br><br><br>Asking, because in Philly the general consensus, I fel,t was people want to move away from the current system level package stuff and move towards: venv's, "lightweight packages", containers.  The only reason that was brought up to keep packages around was to solve the non-python lib stuff and using a depsolver (yum/apt) that doesn't suck (pip).  So I am pretty sure my wants are inline with what other people in the community are either already doing or moving towards.<br>___________________________________________<br><br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br>From: John Dewey <john@dewey.ws<mailto:john@dewey.ws>><br>Date: Wednesday, July 8, 2015 at 11:43 PM<br>To: "Kris G. Lindgren" <klindgren@godaddy.com<mailto:klindgren@godaddy.com>><br>Cc: Adam Young <ayoung@redhat.com<mailto:ayoung@redhat.com>>, "openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>><br>Subject: Re: [Openstack-operators] OSAD for RHEL<br><br>This would not be acceptable for those running OSP.<br><br><br>On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote:<br><br>I should be more clear. My current thought is to have a venv packaged<br>inside an rpm - so the rpm includes the needed init scripts, ensures the<br>required system level binaries are installed, adds the users - ect ect.<br>But would be a single deployable autonomous unit. Also, have a versioning<br>schema to roll forward and back between venvs for quick update/rollback.<br>We are already working on doing something similar to this to run kilo on<br>cent6 boxen, until we can finish revving the remaining parts of the fleet<br>to cent7.<br><br>My desire is to move away from using system level python & openstack<br>packages, so that I can possibly run mismatched versions if I need to. We<br>had a need to run kilo ceilometer and juno neutron/nova on a single<br>server. The conflicting python requirements between those made that task<br>impossible. In general I want to get away from treating Openstack as a<br>single system that everything needs to be upgraded in lock step (packages<br>force you into this). I want to move to being able to upgrade say<br>oslo.messaging to a newer version on just say nova on my control plane<br>servers. Or upgrade nova to kilo while keeping the rest of the system<br>(neutron) on juno. Unless I run each service in a vm/container or on a<br>physical piece of hardware that is pretty much impossible to do with<br>packages - outside of placing everything inside venv's.<br><br>However, it is my understanding that OSAD already builds its own<br>python-wheels and runs those inside lxc containers. So I don?t really<br>follow what good throwing those into an rpm would really do?<br>____________________________________________<br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br>On 7/8/15, 10:33 PM, "Adam Young" <ayoung@redhat.com<mailto:ayoung@redhat.com>> wrote:<br><br>On 07/07/2015 05:55 PM, Kris G. Lindgren wrote:<br>+1 on RHEL support. I have some interest in moving away from packages<br>and<br>am interested in the OSAD tooling as well.<br><br>I would not recommend an approach targetting RHEL that does not use<br>packages.<br><br>OSAD support for RHEL using packages would be an outstanding tool.<br><br>Which way are you planning on taking it?<br><br>____________________________________________<br>Kris Lindgren<br>Senior Linux Systems Engineer<br>GoDaddy, LLC.<br><br><br><br><br><br><br><br>On 7/7/15, 3:38 PM, "Abel Lopez" <alopgeek@gmail.com<mailto:alopgeek@gmail.com>> wrote:<br><br>Hey everyone,<br>I've started looking at osad, and I like much of the direction it<br>takes.<br>I'm pretty interested in developing it to run on RHEL, I just wanted to<br>check if anyone would be -2 opposed to that before I spend cycles on<br>it.<br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/f2496000/attachment-0001.html><br><br>------------------------------<br><br>Message: 10<br>Date: Tue, 14 Jul 2015 16:46:33 -0700<br>From: pra devOPS <siv.devops@gmail.com><br>To: matt <matt@nycresistor.com>,<br>   openstack-operators@lists.openstack.org<br>Subject: Re: [Openstack-operators] FAiled to create instance wiht<br>    openstack nova network<br>Message-ID:<br>   <CANvYX9Wcq-YtP8OxhBO2-ygMywW0+xMrB0veV1vQc1ieDXtKLQ@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi All:<br><br>I was able to spin up instances on openstack (all in one , Icehouse). Got<br>the ips able to connect it to the ips with floating ips.<br><br>from the floating ip network i am able to connect to the machines. Now I<br>want this vms talk outside the host on which they are hosted?<br><br>How can I do that?<br><br>Thanks,<br>Dev<br><br>On Mon, Jul 13, 2015 at 12:07 PM, pra devOPS <siv.devops@gmail.com> wrote:<br><br>><br>> Can somebody suggest me on the below?<br>><br>> Thanks,<br>> Dev<br>><br>> On Fri, Jul 10, 2015 at 4:32 PM, pra devOPS <siv.devops@gmail.com> wrote:<br>><br>>> Hi<br>>><br>>> I am running as root, Please find below the nova config file. ( I am<br>>> using nova network)<br>>><br>>> http://paste.openstack.org/show/363300/<br>>><br>>> Thanks,<br>>> Dev<br>>><br>>> On Fri, Jul 10, 2015 at 1:30 PM, matt <matt@nycresistor.com> wrote:<br>>><br>>>> root-wrap failed probably a config error.  might want to post your nova<br>>>> configs with commenting out of passwords / service tokens.<br>>>><br>>>> dnsmasq --strict-order --bind-interfaces --conf-file= --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.22.1 --except-interface=lo --dhcp-range=set:demo-net,192.168.22.2,static,255.255.255.0,120s --dhcp-lease-max=256 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro --domain=novalocal --no-hosts --addn-hosts=/var/lib/nova/networks/nova-br100.hosts<br>>>> 2015-07-10 15:30:29.753 3044 TRACE oslo.messaging.rpc.dispatcher Exit code: 2<br>>>><br>>>> needs to run as root.  exit code 2 is obviously pretty bad.  so that NEEDs to be fixed.<br>>>><br>>>><br>>>><br>>>> On Fri, Jul 10, 2015 at 3:25 PM, pra devOPS <siv.devops@gmail.com><br>>>> wrote:<br>>>><br>>>>> All:<br>>>>><br>>>>> I get the following error when trying to create an instance in<br>>>>> openstack icehouse centOS 7 on nova network.<br>>>>><br>>>>> nova network logs and UI logs are pasted at:<br>>>>> *http://paste.openstack.org/show/362706/<br>>>>> <http://paste.openstack.org/show/362706/>*<br>>>>><br>>>>><br>>>>><br>>>>> Can somebdody give susggestiong?<br>>>>> Thanks,Siva<br>>>>><br>>>>><br>>>>> _______________________________________________<br>>>>> OpenStack-operators mailing list<br>>>>> OpenStack-operators@lists.openstack.org<br>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>>>>><br>>>>><br>>>><br>>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150714/20bed3b5/attachment-0001.html><br><br>------------------------------<br><br>Message: 11<br>Date: Wed, 15 Jul 2015 16:13:06 +0800<br>From: Tom Fifield <tom@openstack.org><br>To: openstack-operators@lists.openstack.org<br>Subject: Re: [Openstack-operators] Scaling the Ops Meetup<br>Message-ID: <55A61612.10905@openstack.org><br>Content-Type: text/plain; charset=utf-8<br><br>Hi all,<br><br>On 01/07/15 15:29, Tom Fifield wrote:<br>> =Open Questions=<br>...<br>> * What are the costs involved in hosting one of these events?<br><br>Thanks to our wonderful sponsors (any inaccuracies or estimates are<br>mine), I got permission to post some rough cost information for the past<br>events, as requested:<br><br>=1. San Jose=<br>San Jose was hosted by eBay/Paypal who catered breakfast and brought in<br>pizza for lunch.<br><br># Attendees:      40-50<br>Venue cost:       $0<br>Food cost:        $1000<br>Signage/misc:     $0<br>Total per head:   ~$20/head<br><br>Evening Event:    $1000<br><br>=2. San Antonio=<br>San Antonio was hosted by Rackspace over two days who brought in<br>breakfast and pizza/food trucks for lunch.<br><br># Attendees:      80-100<br>Venue cost:       $1100 (security, AV)<br>Food cost:        $2000<br>Signage/misc:     $300<br>Total per head:   ~$33/head<br><br>Evening Event:    $1500<br><br><br>=3. Philadelphia=<br>Philadelphia was our first meetup held in a commercial venue, after we<br>ran out of space to host it at Comcast and had to move it at the last<br>minute. Two day event.<br><br># Attendees:      125<br>Venue cost:       $20,569 venue+food<br>Food cost:        -<br>Signage/misc:     $320<br>Total per head:   ~$165/head<br><br>Evening Event:    $3000<br><br><br><br>Regards,<br><br><br>Tom<br><br><br><br>> <br>> <br>> Regards,<br>> <br>> <br>> Tom<br>> <br>> <br>> <br>> <br>> On 30/06/15 12:33, Tom Fifield wrote:<br>>> Hi all,<br>>><br>>> Right now, behind-the-scenes, we're working on getting a venue for next<br>>> ops mid-cycle. It's taking a little longer than normal, but rest assured<br>>> it is happening.<br>>><br>>> Why is it so difficult? As you may have noticed, we're reaching the size<br>>> of event where both physically and financially, only the largest<br>>> organisations can host us.<br>>><br>>> We thought we might get away with organising this one old-school with a<br>>> single host and sponsor. Then, for the next, start a brainstorming<br>>> discussion with you about how we scale these events into the future -<br>>> since once we get up and beyond a few hundred people, we're looking at<br>>> having to hire a venue as well as make some changes to the format of the<br>>> event.<br>>><br>>> However, it seems that even this might be too late. We already had a<br>>> company that proposed to host the meetup at a west coast US hotel<br>>> instead of their place, and wanted to scope out other companies to<br>>> sponsor food.<br>>><br>>> This would be a change in the model, so let's commence the discussion of<br>>> how we want to scale this event :)<br>>><br>>> So far I've heard things like:<br>>> * "my $CORPORATE_BENEFACTOR would be fine to share sponsorship with others"<br>>> * "I really don't want to get to the point where we want booths at the<br>>> ops meetup"<br>>><br>>> Which are promising! It seems like we have a shared understanding of<br>>> what to take this forward with.<br>>><br>>> So, as the ops meetup grows - what would it look like for you?<br>>><br>>> How do you think we can manage the venue selection and financial side of<br>>> things? What about the session layout and the scheduling with the<br>>> growing numbers of attendees?<br>>><br>>> Current data can be found at<br>>> https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection .<br>>><br>>> I would also be interested in your thoughts about how these events have<br>>> only been in a limited geographical area so far, and how we can address<br>>> that issue.<br>>><br>>><br>>> Regards,<br>>><br>>><br>>> Tom<br>>><br>>><br>>><br>>> _______________________________________________<br>>> OpenStack-operators mailing list<br>>> OpenStack-operators@lists.openstack.org<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>>><br>> <br>> <br>> _______________________________________________<br>> OpenStack-operators mailing list<br>> OpenStack-operators@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>> <br><br><br><br><br>------------------------------<br><br>Message: 12<br>Date: Wed, 15 Jul 2015 10:41:24 +0100<br>From: Pedro Sousa <pgsousa@gmail.com><br>To: "OpenStack-operators@lists.openstack.org"<br>    <openstack-operators@lists.openstack.org><br>Subject: [Openstack-operators] Neutron LBaaS HA in KIlo?<br>Message-ID:<br>        <CA+E02ZDQ5diz8VzNX5JUtmTHvZHFTzPEcN4WSQnK_sCRXdQjWA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all,<br><br>can anybody clarify if Neutron LBaaS Agent has HA support in Kilo?<br><br>Regards,<br>Pedro Sousa<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150715/a337901e/attachment.html><br><br>------------------------------<br><br>_______________________________________________<br>OpenStack-operators mailing list<br>OpenStack-operators@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br><br>End of OpenStack-operators Digest, Vol 57, Issue 19<br>***************************************************</div>