<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Unsubscribe please.<br><br>> From: openstack-dev-request@lists.openstack.org<br>> Subject: OpenStack-dev Digest, Vol 38, Issue 37<br>> To: openstack-dev@lists.openstack.org<br>> Date: Tue, 9 Jun 2015 20:28:10 +0000<br>> <br>> Send OpenStack-dev mailing list submissions to<br>>  openstack-dev@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-dev<br>> or, via email, send a message with subject or body 'help' to<br>>  openstack-dev-request@lists.openstack.org<br>> <br>> You can reach the person managing the list at<br>>  openstack-dev-owner@lists.openstack.org<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of OpenStack-dev digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>>    1. [all] starting oslo releases without namespace packages<br>>       (Doug Hellmann)<br>>    2. Re: [oslo] oslo releasing is noisy... (Victor Stinner)<br>>    3. Re: [javascript] Linters (Michael Krotscheck)<br>>    4. Re: [horizon][i18n] Ordering of PO files (Thai Q Tran)<br>>    5. [release][openstackclient] cliff release 1.13.0 (liberty)<br>>       (doug@doughellmann.com)<br>>    6. Re: [nova] [glance] How to deal with aborted image read?<br>>       (Chris Friesen)<br>>    7. Re: [kolla] Proposal for changing 1600UTC meeting to 1700 UTC<br>>       (Paul Bourke)<br>>    8. Re: [oslo] oslo releasing is noisy... (Thierry Carrez)<br>>    9. Re: [Fuel][Oslo][RabbitMQ][Shovel] Deprecate mirrored queues<br>>       from HA AMQP cluster scenario (Michael Klishin)<br>>   10. [puppet] Weekly meeting #37 (Emilien Macchi)<br>>   11. [nova] FreeBSD host support, round 2 (Roman Bogorodskiy)<br>>   12. Re: [all] Switching to SQLAlchemy 1.0.x (Mike Bayer)<br>>   13. Re: [nova] FreeBSD host support, round 2 (Daniel P. Berrange)<br>>   14. Re: [Openstack-operators]<br>>       [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries<br>>       in addn_hosts causing no IP allocation (Shraddha Pandhe)<br>>   15. (re)centralizing library release management (Doug Hellmann)<br>>   16. Re: [infra] how to trigger a set of jenkins jobs (Anita Kuno)<br>>   17. Re: [release][oslo] oslo.middleware release 2.0.0 (liberty)<br>>       (Doug Hellmann)<br>>   18. Re: [all] Switching to SQLAlchemy 1.0.x (Mike Bayer)<br>>   19. Re: Please Merge patches titled "Merge Tag ..." (Jeremy Stanley)<br>>   20. Re: [kolla] Proposal for changing 1600UTC meeting to 1700 UTC<br>>       (Jeff Peeler)<br>>   21. Re: [infra] how to trigger a set of jenkins jobs (Zaro)<br>>   22. [Keystone]  Midcycle (Adam Young)<br>>   23. Re: [release][oslo] oslo.middleware release 2.0.0 (liberty)<br>>       (Joe Gordon)<br>>   24. [neutron][vpnaas][barbican] What types of authentication to<br>>       support? (Paul Michali)<br>>   25. Re: (re)centralizing library release management (Robert Collins)<br>>   26. Re: [Neutron] API Extensions - Namespace URLs (Jay Pipes)<br>>   27. Re: [all] Switching to SQLAlchemy 1.0.x (Joe Gordon)<br>>   28. Re: [Neutron] API Extensions - Namespace URLs (Brandon Logan)<br>>   29. [kolla] Scheduling for a mid-cycle - doodle poll inside<br>>       (Steven Dake (stdake))<br>>   30. Re: [infra] how to trigger a set of jenkins jobs (Simon McCartney)<br>>   31. Re: [Neutron] API Extensions - Namespace URLs (Kevin Benton)<br>>   32. Fwd:  [neutron] - L3 scope-aware security groups (Carl Baldwin)<br>>   33. [puppet] Move to rspec-puppet 2.2.0 (Cody Herriges)<br>>   34. Re: [javascript] Linters (Michael Krotscheck)<br>>   35. Gerrit downtime on Friday 2015-06-12 at 22:00 UTC (James E. Blair)<br>>   36. [sahara] Migrating to use Keystone Session objects<br>>       (michael mccune)<br>>   37. [murano] shellcheck all .sh scripts in murano-deployment<br>>       (Kirill Zaitsev)<br>>   38. [Ironic] Mid-Cycle Sprint (Stafford, John Richard)<br>>   39. Re: (re)centralizing library release management (Doug Hellmann)<br>>   40. [Ironic] subteam status report (Ruby Loo)<br>>   41. Re: [Neutron] API Extensions - Namespace URLs (Salvatore Orlando)<br>>   42. Request to post to this list EOM (Sousou, Imad)<br>>   43. OpenStack Diversity Working Group (Sousou, Imad)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Tue, 09 Jun 2015 11:57:02 -0400<br>> From: Doug Hellmann <doug@doughellmann.com><br>> To: openstack-dev <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [all] starting oslo releases without<br>>  namespace packages<br>> Message-ID: <1433863746-sup-9209@lrrr.local><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> Today we started releasing versions of some of the Oslo libraries<br>> without the "oslo" namespace package. This represents a<br>> backwards-incompatible API change, so we have raised the major version<br>> number on those libraries where appropriate (oslo.vmware is not yet 1.0,<br>> so we didn't raise the major version there).<br>> <br>> There are several more libraries to be released in the coming weeks, as<br>> part of the remove-namespace-packages blueprint. We expect to have all<br>> of them done by the end of liberty, and I am submitting changes to the<br>> global requirements list to raise the minimum supported versions of each<br>> lib as versions without the package are tagged.<br>> <br>> Doug<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Tue, 09 Jun 2015 18:01:30 +0200<br>> From: Victor Stinner <vstinner@redhat.com><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [oslo] oslo releasing is noisy...<br>> Message-ID: <55770DDA.7030106@redhat.com><br>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>> <br>> Le 09/06/2015 17:50, Jordan Pittier a ?crit :<br>> > Hi,<br>> > This has already been discussed here:<br>> > http://lists.openstack.org/pipermail/openstack-dev/2015-March/059020.html<br>> ><br>> > You can always create a filter to match these emails.<br>> <br>> Well, I'm doing "the opposite": I want to read (all) Oslo emails, so I <br>> move them into a dedicated folder in my mail box ;-)<br>> <br>> I like these release emails to see what changes, especially because Oslo <br>> releases break things sometimes ;-) It's better to stay tuned.<br>> <br>> Victor<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Tue, 09 Jun 2015 16:01:41 +0000<br>> From: Michael Krotscheck <krotscheck@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [javascript] Linters<br>> Message-ID:<br>>  <CABM65av2xD3b5R2VPcHniUuhRDXy4fMvkPg3bX05EFiAR2RO=w@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Well, it looks like everyone has disqualified jslint and jshint, so let's<br>> just make a decision there and remove them from the running. Unless I hear<br>> a compelling reason to use something that has the infamous "do no evil"<br>> license in it, let's dump it.<br>> <br>> The John Papa styles seem sane, and though I disagree with them, I'd be ok<br>> using them. Putting everything in a closure is an old standard that has<br>> usually just annoyed me, since it's one of those things about javascript<br>> that _shouldn't_ have to be explicit, but no language is perfect ;). The<br>> existing eslint stylesheets that exist in StoryBoard and others were<br>> written with PEP8 in mind, in order to facilitate readability between our<br>> languages, however I am also a strong believer in treating JavaScript on<br>> equal terms with other languages. Also, John papa seems to have more<br>> opinions about angular apps than javascript in general, so I propose this<br>> rule for OpenStack going forward:<br>> <br>> 1- If the John Papa rules have an opinion, use that.<br>> 2- Otherwise, use pep8 (where applicable).<br>> 3- Otherwise, check to see if there's a thing in hacking.<br>> 4- If it's in none of those, we'll address it on a case by case basis.<br>> <br>> The main reasons for this is that I simply do not want to have an argument<br>> about spaces vs. tabs. The arguments about PEP8 have already been had, and<br>> the benefits of a language-wide enforced style are simple: We can argue<br>> about more important things! :). Let's assume a week of commentary on the<br>> above.<br>> <br>> As for how this is synchronized, a brief discussion in the infra channel<br>> proposed that we put global javascript requirements in the<br>> global-requirements repo, and then update the update.py script in that repo<br>> to also handle bower.json and package.json. Then, if we build an<br>> eslint/jscs plugin similar to our hacking rules, we can just update that<br>> when we want to modify the linting rules. Any objections?<br>> <br>> With regards to JSCS vs. Eslint, I feel that we actually have to use both<br>> to decide which is better: Once we set up the rules side by side and try to<br>> apply them against a project, a clear winner will emerge. Does anyone want<br>> to volunteer to put together a spreadsheet of all the rules from John Papa<br>> and pep8 that we'd like to enforce, and the appropriate rule in eslint<br>> and/or jscs that applies?<br>> <br>> Michael<br>> <br>> On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S <travis.tripp@hp.com> wrote:<br>> <br>> > We?ve adopted the John Papa style guide for Angular in horizon [0]. On<br>> > cursory inspection ES lint seems to have an angular specific plugin [1]<br>> > that could be very useful to us, but we?d need to evaluate it in depth. It<br>> > looks like there was some discussion on the style guide on this not too<br>> > long ago [2]. The jscs rules we have [3] are very generic code formatting<br>> > type rules that are helpful, but don't really provide any angular specific<br>> > help. Here are the jshint rules [4]. It would be quite nice to put all<br>> > this goodness across tools into a single tool configuration if possible.<br>> ><br>> > [0]<br>> > http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty<br>> > le-guide<br>> > <http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide><br>> > [1] https://www.npmjs.com/package/eslint-plugin-angular<br>> > [2] https://github.com/johnpapa/angular-styleguide/issues/194<br>> > [3] https://github.com/openstack/horizon/blob/master/.jscsrc<br>> > [4] https://github.com/openstack/horizon/blob/master/.jshintrc<br>> ><br>> > On 6/8/15, 9:59 PM, "gustavo panizzo (gfa)" <gfa@zumbi.com.ar> wrote:<br>> ><br>> > ><br>> > ><br>> > >On 2015-06-06 03:26, Michael Krotscheck wrote:<br>> > >> Right now, there are several JS linters in use in OpenStack: JSHint,<br>> > >> JSCS, and Eslint. I really would like to only use one of them, so that I<br>> > >> can figure out how to sanely share the configuration between projects.<br>> > >><br>> > >> Can all those who have a strong opinion please stand up and state their<br>> > >> opinions?<br>> > ><br>> > >what about https://bitbucket.org/dcs/jsmin/ it's license is free<br>> > ><br>> > ><br>> > >--<br>> > >1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333<br>> > ><br>> > >keybase: http://keybase.io/gfa<br>> > ><br>> > >__________________________________________________________________________<br>> > >OpenStack Development Mailing List (not for usage questions)<br>> > >Unsubscribe:<br>> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> ><br>> ><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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/dcdadc45/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Tue, 9 Jun 2015 10:18:01 -0600<br>> From: Thai Q Tran <tqtran@us.ibm.com><br>> To: "OpenStack Development Mailing List \(not for usage questions\)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [horizon][i18n] Ordering of PO files<br>> Message-ID:<br>>  <OF8226D0F6.A902C666-ON87257E5F.00598A6E-87257E5F.00598A70@us.ibm.com><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/08fa9bdb/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Tue, 09 Jun 2015 12:20:48 -0400<br>> From: doug@doughellmann.com<br>> To: openstack-dev@lists.openstack.org<br>> Subject: [openstack-dev] [release][openstackclient] cliff release<br>>  1.13.0 (liberty)<br>> Message-ID: <20150609162049.08417680174@frontend2.nyi.internal><br>> <br>> We are happy to announce the release of:<br>> <br>> cliff 1.13.0: Command Line Interface Formulation Framework<br>> <br>> This release is part of the liberty release series.<br>> <br>> With source available at:<br>> <br>>     http://git.openstack.org/cgit/openstack/cliff<br>> <br>> For more details, please see the git log history below and:<br>> <br>>     https://launchpad.net/python-cliff/+milestone/1.13.0<br>> <br>> Please report issues through launchpad:<br>> <br>>     https://bugs.launchpad.net/python-cliff<br>> <br>> Changes in cliff 1.12.0..1.13.0<br>> -------------------------------<br>> <br>> 8a4a93f Fix object has no attribute debug error<br>> c904cd0 Add some docs for list value formatter<br>> 24120da Add value format for list command<br>> bacb4c6 Updated from global requirements<br>> ec7549c Remove run_cross_tests.sh<br>> f8549ff fix author contact details<br>> efdbc03 Print help on help command<br>> 6d29200 Add documentation for the value formatter<br>> a84421e Sort the fuzzy matches<br>> b6efad3 Defer interactive import<br>> <br>> Diffstat (except docs and test files)<br>> -------------------------------------<br>> <br>> .gitignore                           |  4 +++<br>> cliff/app.py                         | 10 ++++--<br>> cliff/formatters/value.py            | 10 +++++-<br>> cliff/help.py                        |  5 +--<br>> requirements.txt                     |  2 +-<br>> setup.cfg                            |  5 +--<br>> 11 files changed, 100 insertions(+), 97 deletions(-)<br>> <br>> <br>> Requirements updates<br>> --------------------<br>> <br>> diff --git a/requirements.txt b/requirements.txt<br>> index 0bc229b..0a48fca 100644<br>> --- a/requirements.txt<br>> +++ b/requirements.txt<br>> @@ -4 +4 @@<br>> -pbr>=0.6,!=0.7,<1.0<br>> +pbr>=0.11,<2.0<br>> <br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 6<br>> Date: Tue, 9 Jun 2015 10:21:49 -0600<br>> From: Chris Friesen <chris.friesen@windriver.com><br>> To: <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [nova] [glance] How to deal with aborted<br>>  image read?<br>> Message-ID: <5577129D.9060506@windriver.com><br>> Content-Type: text/plain; charset="utf-8"; format=flowed<br>> <br>> On 06/08/2015 06:26 PM, Robert Collins wrote:<br>> > On 9 June 2015 at 07:53, Chris Friesen <chris.friesen@windriver.com> wrote:<br>> >>  From what I understand, the iterator (in the glance-api process) normally<br>> >> breaks out of the while loop once the whole file has been read and the<br>> >> read() call returns an empty string.<br>> >><br>> >> It's not clear to me how an error in the nova process (which causes it to<br>> >> stop reading the file from glance-api)  will cause glance-api to break out<br>> >> of the while loop in ChunkedFile.__iter__().<br>> ><br>> > AIUI the conclusion of our IRC investigation was:<br>> >   - with caching middleware, the fd is freed, just after ~4m.<br>> >   - without caching middleware, the fd is freed after ~90s.<br>> <br>> Correct. I went back and tried it out in a hardware lab and those are the <br>> results I got.  Sorry for the noise (though it'd be nice to get rid of the <br>> 4-minute delay).<br>> <br>> I did a bit more digging and we've apparently got another similar issue reported <br>> where taking a snapshot fails because the filesystem fills up and the space <br>> never gets reclaimed even though the snapshot failed.  I'll make sure I can <br>> reproduce that one before going further.<br>> <br>> Chris<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 7<br>> Date: Tue, 09 Jun 2015 17:25:14 +0100<br>> From: Paul Bourke <paul.bourke@oracle.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [kolla] Proposal for changing 1600UTC<br>>  meeting to 1700 UTC<br>> Message-ID: <5577136A.5080503@oracle.com><br>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>> <br>> Actually I misread the time, 1700 UTC is 6pm Irish time which is not as <br>> good for me.<br>> <br>> So -1<br>> <br>> On 09/06/15 09:30, Paul Bourke wrote:<br>> > +1<br>> ><br>> > On 08/06/15 18:37, Smigiel, Dariusz wrote:<br>> >>> Folks,<br>> >>><br>> >>> Several people have messaged me from EMEA timezones that 1600UTC fits<br>> >>> right into the middle of their family life (ferrying kids from school<br>> >>> and what-not) and 1700UTC while not perfect, would be a better fit<br>> >>> time-wise.<br>> >>><br>> >>> For all people that intend to attend the 1600 UTC, could I get your<br>> >>> feedback on this thread if a change of the 1600UTC timeslot to<br>> >>> 1700UTC would be acceptable?  If it wouldn't be acceptable, please<br>> >>> chime in as well.<br>> >>><br>> >>> Thanks<br>> >>> -steve<br>> >><br>> >> +1<br>> >> It suits me.<br>> >><br>> ><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>> Message: 8<br>> Date: Tue, 09 Jun 2015 18:31:12 +0200<br>> From: Thierry Carrez <thierry@openstack.org><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [oslo] oslo releasing is noisy...<br>> Message-ID: <557714D0.4020705@openstack.org><br>> Content-Type: text/plain; charset=windows-1252<br>> <br>> Victor Stinner wrote:<br>> > Le 09/06/2015 17:50, Jordan Pittier a ?crit :<br>> >> Hi,<br>> >> This has already been discussed here:<br>> >> http://lists.openstack.org/pipermail/openstack-dev/2015-March/059020.html<br>> >><br>> >> You can always create a filter to match these emails.<br>> > <br>> > Well, I'm doing "the opposite": I want to read (all) Oslo emails, so I<br>> > move them into a dedicated folder in my mail box ;-)<br>> > <br>> > I like these release emails to see what changes, especially because Oslo<br>> > releases break things sometimes ;-) It's better to stay tuned.<br>> <br>> We are currently exploring the option to repurpose the<br>> openstack-announce ML to be the extensive record of release<br>> announcements. It's part of a larger plan to streamline library<br>> releases, about which Doug should start a discussion pretty soon now.<br>> <br>> If we did that, we'd likely post to openstack-announce with Reply-To set<br>> to openstack-dev (so that any discussion on the recent release would<br>> happen on the open list).<br>> <br>> -- <br>> Thierry Carrez (ttx)<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 9<br>> Date: Tue, 9 Jun 2015 19:38:27 +0300<br>> From: Michael Klishin <mklishin@pivotal.io><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [Fuel][Oslo][RabbitMQ][Shovel] Deprecate<br>>  mirrored queues from HA AMQP cluster scenario<br>> Message-ID: <etPan.55771690.7125e72.1209d@mercurio.local><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> On 9 June 2015 at 10:26:27, Michael Klishin (mklishin@pivotal.io) wrote:<br>> > I will push for introducing the most basic timeout support<br>> > in ctl in the next bug fix release.<br>> <br>> Some (highly conservative, for the sake of backwards compatibility)<br>> improvements are already merged and will be in 3.5.4 :<br>> <br>> https://github.com/rabbitmq/rabbitmq-server/pull/181<br>> -- <br>> MK <br>> <br>> Staff Software Engineer, Pivotal/RabbitMQ <br>> <br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 10<br>> Date: Tue, 09 Jun 2015 12:53:22 -0400<br>> From: Emilien Macchi <emilien@redhat.com><br>> To: OpenStack Development Mailing List<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [puppet] Weekly meeting #37<br>> Message-ID: <55771A02.1070502@redhat.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Our meeting minutes this week:<br>> <br>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-09-15.00.html<br>> <br>> Thanks everyone,<br>> -- <br>> Emilien Macchi<br>> <br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: signature.asc<br>> Type: application/pgp-signature<br>> Size: 473 bytes<br>> Desc: OpenPGP digital signature<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/01422e19/attachment-0001.pgp><br>> <br>> ------------------------------<br>> <br>> Message: 11<br>> Date: Tue, 9 Jun 2015 19:52:39 +0300<br>> From: Roman Bogorodskiy <novel@FreeBSD.org><br>> To: openstack-dev@lists.openstack.org<br>> Subject: [openstack-dev] [nova] FreeBSD host support, round 2<br>> Message-ID: <20150609165231.GA3492@kloomba><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Hi,<br>> <br>> Few months ago I've started a discussion on FreeBSD host support for<br>> OpenStack. [1] At a result of discussion it was figured out that there<br>> are a number of limitations, mainly on the BHyVe (the FreeBSD hypervisor)<br>> side, that make the effort not feasible.<br>> <br>> However, some things changed since then. Specifically, FreeBSD's got Xen<br>> dom0 support. [2] In context of OpenStack deployment that has a number of<br>> benefits over bhyve. Specifically:<br>> <br>>  * The stack is more mature and feature-rich<br>>  * The toolstack is here already: libxl is available through the FreeBSD<br>>    ports tree, libvirt/libxl works there with minimal modifications<br>>    (already available in the git master)<br>>  * OpenStack libvirt/libxl driver is already here<br>> <br>> I was able to setup a proof-of-concept environment on FreeBSD that<br>> required quite a small amount of modifications required in OpenStack:<br>> <br>>  * Glance and Keystone didn't require any changes<br>>  * Nove required some minor modifications mainly in the linux_net.py<br>>    area<br>> <br>> The summary of Nova modifications:<br>> <br>>  * I had to implement FreeBSD version of linux_net.LinuxNetInterfaceDriver.<br>>    It currently doesn't support vlans though. <br>> <br>>    https://github.com/novel/bsdstack/blob/master/bsdstack/nova/network/freebsd_net.py<br>> <br>>    I keep it as an external package and configure Nova to use it through<br>>    linuxnet_interface_driver config option in nova.conf<br>>  * I had to create a stub for the IptablesManager class. I also had to<br>>    add a config option to be able to override class for that in a way<br>>    similar to interface driver.<br>>  * I had to fix a minor interface incapability for NullL3 stub, that's<br>>    already in the Nova tree: https://review.openstack.org/#/c/189001/<br>>  * I added a hack to use 'phy' driver in domain's xml for disks because<br>>    for some reason driver='qemu' results in guests not able to access<br>>    disk devices (tried both FreeBSD and Linux guests). Need to<br>>    investigate<br>>  * Dropped some LinuxBridgeInterfaceDriver hardcodes in<br>>    virt.libvirt.vif.<br>> <br>> Here's a quick overview of my changes:<br>> <br>> https://github.com/novel/nova/compare/stable/kilo...novel:stable/kilo_freebsd?expand=1<br>> <br>> With this changes I was able to get things working, i.e. VM starting,<br>> obtaining IP addresses (with nova-network configured with FlatDHCP) etc.<br>> <br>> Having that said I'm wondering if community is interested in integrating<br>> FreeBSD support through libvirt/libxl into mainline? Obviously, the<br>> changes I provided are shortcuts and the appropriate specs should be<br>> create with proposals of proper designs, not quick hacks like that.<br>> <br>> The biggest part of the unportable code, just like it was in bhyve case,<br>> is still linux_net.py, so probably it makes sense to revive the old<br>> spec:<br>> <br>> https://review.openstack.org/#/c/127827/<br>> <br>> TBH, IMHO linux_net.py could have a refactor regardless of FreeBSD<br>> support. It's approx. 2000 lines long, contains a lot of stuff like<br>> dnsmasq handling code, interface handing code and firewall management<br>> that could have their own place.<br>> <br>> Feedback is appreciated,<br>> Thanks<br>> <br>> 1: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048721.html<br>> 2: http://wiki.xen.org/wiki/FreeBSD_Dom0<br>> <br>> Roman Bogorodskiy<br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: not available<br>> Type: application/pgp-signature<br>> Size: 473 bytes<br>> Desc: not available<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/3a9d2d24/attachment-0001.pgp><br>> <br>> ------------------------------<br>> <br>> Message: 12<br>> Date: Tue, 9 Jun 2015 13:08:23 -0400<br>> From: Mike Bayer <mbayer@redhat.com><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x<br>> Message-ID: <55771D87.3070106@redhat.com><br>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>> <br>> <br>> <br>> On 6/9/15 9:26 AM, Thomas Goirand wrote:<br>> > Hi,<br>> ><br>> > The python-sqlalchemy package has been uploaded to Debian Experimental,<br>> > and is about to be uploaded to Debian Unstable. So I wonder what's the<br>> > state of the project regarding upgrading SQLA.<br>> ><br>> > Maybe Mike can tell what kind of issue we may run into? How much work<br>> > will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be<br>> > compatible with both 9.x and 1.x (which would be the best way forward)?<br>> <br>> The short answer is that there are no supported use cases that have been <br>> intentionally changed in any backwards incompatible way in 1.0 and all <br>> Openstack code should be able to accommodate from 0.9.x -> 1.0.x without <br>> any change.<br>> <br>> I run SQLAlchemy's master against a small subset of Openstack tests <br>> continuously, including Nova DB API, Keystone, all of oslo.db and <br>> Neutron's migration tests, and there was nothing that needed changing as <br>> we went along.   I've also run devstack against SQLAlchemy 1.0 without <br>> problems though I don't have a lot of openstack-user-fu so I didn't <br>> stress test it too much at that level.<br>> <br>> It's my expectation that nothing in Openstack should have to change to <br>> work with SQLAlchemy 1.0 - the kinds of things that change tend to be <br>> subtle things related to odd use cases and newer features, usually along <br>> the lines of applications that may have been relying upon some behavior <br>> that was undefined, that then changes it's behavior in some way.<br>> <br>> An example is that we had a user who was running a query of the form <br>> "session.query(SomeObject).with_parent(SomeParent(id=None))", e.g. <br>> trying to find objects that *didn't* have a parent by using a transient <br>> "Parent" with "id=None" - totally unexpected way of doing that, and it <br>> wasn't even working for that user as it came up with an "= NULL" <br>> comparison that isn't even right, *but* when SQLA 1.0 came around it <br>> started leaking an internal symbol into the query, and *then* it became <br>> noticeable.  That's the kind of thing that "breaks" with new SQLAlchemy <br>> versions these days.   We had a lot of those this time around, and the <br>> vast majority of them were logged as regressions which were fixed and <br>> added to testing.   You can see those by browsing versions 1.0.1 -> <br>> 1.0.5 at http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html.<br>> <br>> We never intentionally make *any* backwards incompatible change in just <br>> one major version without warnings being emitted in the previous <br>> version, and the warnings usually involve urging the user to set a flag <br>> to "use the old way" if they're going to upgrade; that is, we at least <br>> always try to add flags to keep an old behavior in place if at all <br>> possible.   I've not seen anything in Openstack that would be sensitive <br>> to this kind of issue for 1.0.<br>> <br>> So for Openstack, we would mostly worry about code that is doing things <br>> oddly in some unexpected way, however all the Openstack code I've seen <br>> tends to be very ORM centric and uses the ORM very conservatively so I <br>> don't anticipate any problems.   I would note that some silently-/ <br>> quasi- failing use cases for query.update() and query.delete()  now <br>> raise exceptions in 1.0.   They both emit warnings in 0.9 but I just <br>> checked and apparently one of these warnings is only in the as-yet <br>> unreleased 0.9.10.   I've just added an extra migration note for one of <br>> these which appeared to be missing in the migration document (as of this <br>> writing it should be up on RTD within an hour).<br>> <br>> That said, the document which tries to capture everything that might be <br>> surprising is at <br>> http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html.<br>> <br>> <br>> ><br>> > Cheers,<br>> ><br>> > Thomas Goirand (zigo)<br>> ><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: 13<br>> Date: Tue, 9 Jun 2015 18:13:22 +0100<br>> From: "Daniel P. Berrange" <berrange@redhat.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [nova] FreeBSD host support, round 2<br>> Message-ID: <20150609171322.GM2089@redhat.com><br>> Content-Type: text/plain; charset=utf-8<br>> <br>> On Tue, Jun 09, 2015 at 07:52:39PM +0300, Roman Bogorodskiy wrote:<br>> > Hi,<br>> > <br>> > Few months ago I've started a discussion on FreeBSD host support for<br>> > OpenStack. [1] At a result of discussion it was figured out that there<br>> > are a number of limitations, mainly on the BHyVe (the FreeBSD hypervisor)<br>> > side, that make the effort not feasible.<br>> <br>> Do you still intend to add the missing features to BHyve to let it be<br>> supported in Nova eventually too ?<br>> <br>> > However, some things changed since then. Specifically, FreeBSD's got Xen<br>> > dom0 support. [2] In context of OpenStack deployment that has a number of<br>> > benefits over bhyve. Specifically:<br>> > <br>> >  * The stack is more mature and feature-rich<br>> >  * The toolstack is here already: libxl is available through the FreeBSD<br>> >    ports tree, libvirt/libxl works there with minimal modifications<br>> >    (already available in the git master)<br>> >  * OpenStack libvirt/libxl driver is already here<br>> > <br>> > I was able to setup a proof-of-concept environment on FreeBSD that<br>> > required quite a small amount of modifications required in OpenStack:<br>> > <br>> >  * Glance and Keystone didn't require any changes<br>> >  * Nove required some minor modifications mainly in the linux_net.py<br>> >    area<br>> > <br>> > The summary of Nova modifications:<br>> > <br>> >  * I had to implement FreeBSD version of linux_net.LinuxNetInterfaceDriver.<br>> >    It currently doesn't support vlans though. <br>> > <br>> >    https://github.com/novel/bsdstack/blob/master/bsdstack/nova/network/freebsd_net.py<br>> > <br>> >    I keep it as an external package and configure Nova to use it through<br>> >    linuxnet_interface_driver config option in nova.conf<br>> >  * I had to create a stub for the IptablesManager class. I also had to<br>> >    add a config option to be able to override class for that in a way<br>> >    similar to interface driver.<br>> >  * I had to fix a minor interface incapability for NullL3 stub, that's<br>> >    already in the Nova tree: https://review.openstack.org/#/c/189001/<br>> >  * I added a hack to use 'phy' driver in domain's xml for disks because<br>> >    for some reason driver='qemu' results in guests not able to access<br>> >    disk devices (tried both FreeBSD and Linux guests). Need to<br>> >    investigate<br>> >  * Dropped some LinuxBridgeInterfaceDriver hardcodes in<br>> >    virt.libvirt.vif.<br>> > <br>> > Here's a quick overview of my changes:<br>> > <br>> > https://github.com/novel/nova/compare/stable/kilo...novel:stable/kilo_freebsd?expand=1<br>> > <br>> > With this changes I was able to get things working, i.e. VM starting,<br>> > obtaining IP addresses (with nova-network configured with FlatDHCP) etc.<br>> > <br>> > Having that said I'm wondering if community is interested in integrating<br>> > FreeBSD support through libvirt/libxl into mainline? Obviously, the<br>> > changes I provided are shortcuts and the appropriate specs should be<br>> > create with proposals of proper designs, not quick hacks like that.<br>> <br>> I'd be happy to see FreeBSD support for any of the libvirt hypervisors<br>> added to Nova. As you point out, the changes to the libvirt code are<br>> going to be pretty minimal for libxl, so there's not going to be any<br>> appreciable ongoing maint burden for this. So I see no serious reason<br>> to reject the changes to Nova libvirt driver code for libxl+FreeBSD.<br>> The fun bit will be the changes to non-libvirt code in nova...<br>> <br>> > The biggest part of the unportable code, just like it was in bhyve case,<br>> > is still linux_net.py, so probably it makes sense to revive the old<br>> > spec:<br>> > <br>> > https://review.openstack.org/#/c/127827/<br>> > <br>> > TBH, IMHO linux_net.py could have a refactor regardless of FreeBSD<br>> > support. It's approx. 2000 lines long, contains a lot of stuff like<br>> > dnsmasq handling code, interface handing code and firewall management<br>> > that could have their own place.<br>> <br>> Yes, that network setup code is really awful and I'd love to see<br>> it refactored regardless of FreeBSD support.<br>> <br>> With my crystal ball, probably the main question wrt any kind of<br>> FreeBSD support will be that of 3rd party CI testing. I don't know<br>> whether there is any company backing your work who has resources<br>> to provide a CI system, or whether FreeBSD project can manage it<br>> independently ?<br>> <br>> The refactoring of the linux_net.py code could be done even without<br>> CI support of course - that would only block the second part where<br>> you actually add a FreeBSD implementation<br>> <br>> Regards,<br>> Daniel<br>> -- <br>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|<br>> |: http://libvirt.org              -o-             http://virt-manager.org :|<br>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|<br>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 14<br>> Date: Tue, 9 Jun 2015 17:18:30 +0000 (UTC)<br>> From: Shraddha Pandhe <shraddha.pandhe@yahoo.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org>,  Neil Jerram<br>>  <Neil.Jerram@metaswitch.com>,  Daniel Comnea <comnea.dani@gmail.com><br>> Cc: "openstack-operators@lists.openstack.org"<br>>  <openstack-operators@lists.openstack.org><br>> Subject: Re: [openstack-dev] [Openstack-operators]<br>>  [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in<br>>  addn_hosts causing no IP allocation<br>> Message-ID:<br>>  <1063720559.4094099.1433870310850.JavaMail.yahoo@mail.yahoo.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hi Daniel,<br>> I see following in your command<br>> --dhcp-range=set:tag0,192.168.110.0,static,86400s --dhcp-range=set:tag1,192.168.111.0,static,86400s<br>> <br>> Is this expected? Was this command generated by the agent itself, or was Dnsmasq manually started?<br>> <br>> <br>> <br>>  <br>> <br>> <br>> <br>>      On Tuesday, June 9, 2015 4:41 AM, Kevin Benton <blak111@gmail.com> wrote:<br>>    <br>> <br>>  >Just to be sure, I assume we're focussing here on the issue that Daniel reported<br>> Yes.<br>> >To be clear, though, what code are you trying to reproduce on?? Current master?<br>> I was trying on 2014.1.3, which is the version I understand to be on Fuel 5.1.1.<br>> >I'm not clear whether that would qualify as 'concurrent', in the sense that you have in mind.<br>> It doesn't look like it based on the pseudocode. I was thinking of a condition where a port is deleted nearly very quickly after it was created. Is that possible with your test? If not, then my theory about out-of-order notifications might not be any good.<br>> On Tue, Jun 9, 2015 at 3:34 AM, Neil Jerram <Neil.Jerram@metaswitch.com> wrote:<br>> <br>> On 09/06/15 01:15, Kevin Benton wrote:<br>> <br>> I'm having difficulty reproducing the issue. The bug that Neil<br>> referenced (https://bugs.launchpad.net/neutron/+bug/1192381) looks like<br>> it was in Icehouse well before the 2014.1.3 release that looks like Fuel<br>> 5.1.1 is using.<br>> <br>> <br>> Just to be sure, I assume we're focussing here on the issue that Daniel reported (IP appears twice in Dnsmasq config), and for which I described a possible corollary (Dnsmasq config size keeps growing), and NOT on the "Another DHCP agent problem" that I mentioned below. :-)<br>> <br>> BTW, now that I've reviewed the history of when my team saw this, I can say that it was actually first reported to us with the 'IP appears twice in Dnsmasq config' symptom - i.e. exactly the same as Daniel's case. The fact of the Dnsmasq config increasing in size was noticed later.<br>> <br>> <br>> I tried setting the agent report interval to something higher than the<br>> downtime to make it seem like the agent is failing sporadically to the<br>> server, but it's not impacting the notifications.<br>> <br>> <br>> Makes sense - that's the effect of the fix for 1192381.<br>> <br>> To be clear, though, what code are you trying to reproduce on?? Current master?<br>> <br>> <br>> Neil, does your testing where you saw something similar have a lot of<br>> concurrent creation/deletion?<br>> <br>> <br>> It was a test of continuously deleting and creating VMs, with this pseudocode:<br>> <br>> thread_pool = new_thread_pool(size=30)<br>> for x in range(0,30):<br>> ? ? thread_pool.submit(create_vm)<br>> thread_pool.wait_for_all_threads_to_complete()<br>> while True:<br>> ? ? ?time.sleep(5)<br>> ? ? ?for x in range(0,int(random.random()*5)):<br>> ? ? ? ? ? thread_pool.submit(randomly_delete_a_vm_and_create_a_new_one)<br>> <br>> I'm not clear whether that would qualify as 'concurrent', in the sense that you have in mind.<br>> <br>> Regards,<br>> ? ? ? ? Neil<br>> <br>> <br>> On Mon, Jun 8, 2015 at 12:21 PM, Andrew Woodward <awoodward@mirantis.com<br>> <mailto:awoodward@mirantis.com>> wrote:<br>> <br>> ? ? Daniel,<br>> <br>> ? ? This sounds familiar, see if this matches [1]. IIRC, there was<br>> ? ? another issue like this that was might already address this in the<br>> ? ? updates into Fuel 5.1.2 packages repo [2]. You can either update the<br>> ? ? neutron packages from [2] Or try one of community builds for 5.1.2<br>> ? ? [3]. If this doesn't resolve the issue, open a bug against MOS dev [4].<br>> <br>> ? ? [1] https://bugs.launchpad.net/bugs/1295715<br>> ? ? [2] http://fuel-repository.mirantis.com/fwm/5.1.2/ubuntu/pool/main/<br>> ? ? [3] https://ci.fuel-infra.org/<br>> ? ? [4] https://bugs.launchpad.net/mos/+filebug<br>> <br>> ? ? On Mon, Jun 8, 2015 at 10:15 AM Neil Jerram<br>> ? ? <Neil.Jerram@metaswitch.com <mailto:Neil.Jerram@metaswitch.com>> wrote:<br>> <br>> ? ? ? ? Two further thoughts on this:<br>> <br>> ? ? ? ? 1. Another DHCP agent problem that my team noticed is that it<br>> ? ? ? ? call_driver('reload_allocations') takes a bit of time (to<br>> ? ? ? ? regenerate the<br>> ? ? ? ? Dnsmasq config files, and to spawn a shell that sends a HUP<br>> ? ? ? ? signal) -<br>> ? ? ? ? enough so that if there is a fast steady rate of port-create and<br>> ? ? ? ? port-delete notifications coming from the Neutron server, these can<br>> ? ? ? ? build up in DHCPAgent's RPC queue, and then they still only get<br>> ? ? ? ? dispatched one at a time.? So the queue and the time delay<br>> ? ? ? ? become longer<br>> ? ? ? ? and longer.<br>> <br>> ? ? ? ? I have a fix pending for this, which uses an extra thread to<br>> ? ? ? ? read those<br>> ? ? ? ? notifications off the RPC queue onto an internal queue, and then<br>> ? ? ? ? batches<br>> ? ? ? ? the call_driver('reload_allocations') processing when there is a<br>> ? ? ? ? contiguous sequence of such notifications - i.e. only does the<br>> ? ? ? ? config<br>> ? ? ? ? regeneration and HUP once, instead of lots of times.<br>> <br>> ? ? ? ? I don't think this is directly related to what you are seeing - but<br>> ? ? ? ? perhaps there actually is some link that I am missing.<br>> <br>> ? ? ? ? 2. There is an interesting and vaguely similar thread currently<br>> ? ? ? ? being<br>> ? ? ? ? discussed about the L3 agent (subject "L3 agent rescheduling<br>> ? ? ? ? issue") -<br>> ? ? ? ? about possible RPC/threading issues between the agent and the<br>> ? ? ? ? Neutron<br>> ? ? ? ? server.? You might like to review that thread and see if it<br>> ? ? ? ? describes<br>> ? ? ? ? any problems analogous to your DHCP one.<br>> <br>> ? ? ? ? Regards,<br>> ? ? ? ? ? ? ? ? ?Neil<br>> <br>> <br>> ? ? ? ? On 08/06/15 17:53, Neil Jerram wrote:<br>> ? ? ? ? ?> My team has seen a problem that could be related: in a churn<br>> ? ? ? ? test where<br>> ? ? ? ? ?> VMs are created and terminated at a constant rate - but so<br>> ? ? ? ? that the<br>> ? ? ? ? ?> number of active VMs should remain roughly constant - the<br>> ? ? ? ? size of the<br>> ? ? ? ? ?> host and addn_hosts files keeps increasing.<br>> ? ? ? ? ?><br>> ? ? ? ? ?> In other words, it appears that the config for VMs that have<br>> ? ? ? ? actually<br>> ? ? ? ? ?> been terminated is not being removed from the config file.<br>> ? ? ? ? Clearly, if<br>> ? ? ? ? ?> you have a limited pool of IP addresses, this can eventually<br>> ? ? ? ? lead to the<br>> ? ? ? ? ?> problem that you have described.<br>> ? ? ? ? ?><br>> ? ? ? ? ?> For your case - i.e. with Icehouse - the problem might be<br>> ? ? ? ? ?> https://bugs.launchpad.net/neutron/+bug/1192381.? I'm not<br>> ? ? ? ? sure if the<br>> ? ? ? ? ?> fix for that problem - i.e. sending port-create and port-delete<br>> ? ? ? ? ?> notifications to DHCP agents even when the server thinks they<br>> ? ? ? ? are down -<br>> ? ? ? ? ?> was merged before the Icehouse release, or not.<br>> ? ? ? ? ?><br>> ? ? ? ? ?> But there must be at least one other cause as well, because<br>> ? ? ? ? my team was<br>> ? ? ? ? ?> seeing this with Juno-level code.<br>> ? ? ? ? ?><br>> ? ? ? ? ?> Therefore I, too, would be interested in any other insights<br>> ? ? ? ? about this<br>> ? ? ? ? ?> problem.<br>> ? ? ? ? ?><br>> ? ? ? ? ?> Regards,<br>> ? ? ? ? ?>? ? ? Neil<br>> ? ? ? ? ?><br>> ? ? ? ? ?><br>> ? ? ? ? ?><br>> ? ? ? ? ?> On 08/06/15 16:26, Daniel Comnea wrote:<br>> ? ? ? ? ?>> Any help, ideas please?<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>> Thx,<br>> ? ? ? ? ?>> Dani<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>> On Mon, Jun 8, 2015 at 9:25 AM, Daniel Comnea<br>> ? ? ? ? <comnea.dani@gmail.com <mailto:comnea.dani@gmail.com><br>> ? ? ? ? ?>> <mailto:comnea.dani@gmail.com<br>> ? ? ? ? <mailto:comnea.dani@gmail.com>>> wrote:<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ?+ Operators<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ?Much thanks in advance,<br>> ? ? ? ? ?>>? ? ?Dani<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ?On Sun, Jun 7, 2015 at 6:31 PM, Daniel Comnea<br>> ? ? ? ? <comnea.dani@gmail.com <mailto:comnea.dani@gmail.com><br>> ? ? ? ? ?>>? ? ?<mailto:comnea.dani@gmail.com<br>> ? ? ? ? <mailto:comnea.dani@gmail.com>>> wrote:<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?Hi all,<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?I'm running IceHouse (build using Fuel 5.1.1) on<br>> ? ? ? ? Ubuntu where<br>> ? ? ? ? ?>>? ? ? ? ?dnsmask version 2.59-4.<br>> ? ? ? ? ?>>? ? ? ? ?I have a very basic network layout where i have a<br>> ? ? ? ? private net<br>> ? ? ? ? ?>>? ? ? ? ?which has 2 subnets<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ? ?2fb7de9d-d6df-481f-acca-2f7860cffa60 | private-net<br>> ? ? ? ? ?>>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|<br>> ? ? ? ? ?>>? ? ? ? ?e79c3477-d3e5-471c-a728-8d881cf31bee<br>> ? ? ? ? 192.168.110.0/24 <http://192.168.110.0/24><br>> ? ? ? ? ?>>? ? ? ? ?<http://192.168.110.0/24> |<br>> ? ? ? ? ?>>? ? ? ? ?|<br>> ? ? ? ? ?>>? ? ? ? ?|<br>> ? ? ? ? ? ? ? |<br>> ? ? ? ? ?>>? ? ? ? ?f48c3223-8507-455c-9c13-8b727ea5f441<br>> ? ? ? ? 192.168.111.0/24 <http://192.168.111.0/24><br>> ? ? ? ? ?>>? ? ? ? ?<http://192.168.111.0/24> |<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?and i'm creating VMs via HEAT.<br>> ? ? ? ? ?>>? ? ? ? ?What is happening is that sometimes i get duplicated<br>> ? ? ? ? entries in<br>> ? ? ? ? ?>>? ? ? ? ?[1] and because of that the VM which was spun up<br>> ? ? ? ? doesn't get<br>> ? ? ? ? ?>> an ip.<br>> ? ? ? ? ?>>? ? ? ? ?The Dnsmask processes are running okay [2] and i<br>> ? ? ? ? can't see<br>> ? ? ? ? ?>>? ? ? ? ?anything special/ wrong in it.<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?Any idea why this is happening? Or are you aware of<br>> ? ? ? ? any bugs<br>> ? ? ? ? ?>>? ? ? ? ?around this area? Do you see a problems with having<br>> ? ? ? ? 2 subnets<br>> ? ? ? ? ?>>? ? ? ? ?mapped to 1 private-net?<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?Thanks,<br>> ? ? ? ? ?>>? ? ? ? ?Dani<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?[1]<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? /var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/addn_hosts<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?[2]<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?nobody? ? 5664? ? ?1? 0 Jun02 ?? ? ? ? 00:00:08 dnsmasq<br>> ? ? ? ? ?>>? ? ? ? ?--no-hosts --no-resolv --strict-order --bind-interfaces<br>> ? ? ? ? ?>>? ? ? ? ?--interface=tapc9164734-0c --except-interface=lo<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? --pid-file=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/pid<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? --dhcp-hostsfile=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/host<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? --addn-hosts=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/addn_hosts<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? --dhcp-optsfile=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/opts<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>>? ? ? ? ?--leasefile-ro --dhcp-authoritative<br>> ? ? ? ? ?>>? ? ? ? ?--dhcp-range=set:tag0,192.168.110.0,static,86400s<br>> ? ? ? ? ?>>? ? ? ? ?--dhcp-range=set:tag1,192.168.111.0,static,86400s<br>> ? ? ? ? ?>>? ? ? ? ?--dhcp-lease-max=512 --conf-file= --server=10.0.0.31<br>> ? ? ? ? ?>>? ? ? ? ?--server=10.0.0.32 --domain=openstacklocal<br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>><br>> ? ? ? ? ?>> _______________________________________________<br>> ? ? ? ? ?>> OpenStack-operators mailing list<br>> ? ? ? ? ?>> OpenStack-operators@lists.openstack.org<br>> ? ? ? ? <mailto:OpenStack-operators@lists.openstack.org><br>> ? ? ? ? ?>><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>> ? ? ? ? ?><br>> ? ? ? ? http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br>> <br>> ? ? ? ? __________________________________________________________________________<br>> ? ? ? ? OpenStack Development Mailing List (not for usage questions)<br>> ? ? ? ? Unsubscribe:<br>> ? ? ? ? OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> ? ? ? ? <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><br>> ? ? ? ? http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> <br>> ? ? --<br>> ? ? --<br>> ? ? Andrew Woodward<br>> ? ? Mirantis<br>> ? ? Fuel Community Ambassador<br>> ? ? Ceph Community<br>> <br>> ? ? __________________________________________________________________________<br>> ? ? OpenStack Development Mailing List (not for usage questions)<br>> ? ? Unsubscribe:<br>> ? ? OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> ? ? <http://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>> Kevin Benton<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>> Kevin Benton<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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/cc6cf74f/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 15<br>> Date: Tue, 09 Jun 2015 13:25:26 -0400<br>> From: Doug Hellmann <doug@doughellmann.com><br>> To: openstack-dev <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] (re)centralizing library release management<br>> Message-ID: <1433870400-sup-6495@lrrr.local><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> Until now we have encouraged project teams to prepare their own<br>> library releases as new versions of projects were needed. We've<br>> started running into a couple of problems with that, with releases<br>> not coming often enough, or at a bad time in the release cycle, or<br>> with version numbering not being applied consistently, or without<br>> proper announcements. To address these issues, the release management<br>> team is proposing to create a small team of library release managers<br>> to handle the process around all library releases (clients,<br>> non-application projects, middleware, Oslo libraries, etc.). This<br>> will give us a chance to collaborate and review the version numbers<br>> for new releases, as well as stay on top of "stale" libraries with<br>> fixes or features that sit unreleased for a period of time. It will<br>> also be the first step to creating an automated review process for<br>> release tags.<br>> <br>> The process still needs to be worked out, but I envision it working<br>> something like this:<br>> <br>> The release liaison/PTL for the project team submits a request for<br>> a new release, including the repo name, the SHA, the series (liberty,<br>> kilo, etc.), and the proposed version number. The release team<br>> checks the proposed version number against the unreleased changes<br>> up to that SHA, and then either updates it to reflect semver or<br>> uses it as it is provided. The release team would then handle the<br>> tag push and the resulting announcements.<br>> <br>> There would be a few conditions under which a new release might not<br>> be immediately approved, but really only when the gate is wedged<br>> and during freeze periods. The point of the change isn't to block<br>> releases, just ensure consistency and good timing.<br>> <br>> We have some tools to let us look for unreleased changes, and<br>> eventually we can set up a recurring job to build that report so<br>> we can propose releases to project teams with a large release<br>> backlog. That will likely come later, though.<br>> <br>> We can also pre-announce proposed releases if folks find that useful.<br>> <br>> We will need a small number of volunteers to join this team, and<br>> start building the required expertise in understanding the overall<br>> state of the project, and in semantic versioning. We do not necessarily<br>> want a liaison from every project -- think of this as the proto-team<br>> for the group that eventually has core reviewer rights on the release<br>> automation repository.<br>> <br>> Doug<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 16<br>> Date: Tue, 09 Jun 2015 13:39:23 -0400<br>> From: Anita Kuno <anteaya@anteaya.info><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [infra] how to trigger a set of jenkins<br>>  jobs<br>> Message-ID: <557724CB.7040606@anteaya.info><br>> Content-Type: text/plain; charset=windows-1252<br>> <br>> On 06/09/2015 05:33 AM, Gareth wrote:<br>> > Hi infra team,<br>> > <br>> > The origin concept of jenkins is "one trigger one job". For example, the<br>> > job "neutron-unit-test-py27" could respond a new change set from neutron<br>> > upstream. But the truth is that a gerrit event trigger a set of jenkins<br>> > jobs: py27-unittest, pep8-check, and many dsvm jobs...<br>> > <br>> > How can I configure my jenkins like this?<br>> > <br>> > <br>> > <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>> We use a tool called Zuul written expressly for our needs which has a<br>> concept of pipelines. The status of the patch in Gerrit (Workflow 0,<br>> Workflow +1, merged) gives Zuul the information it needs to put a<br>> patchset in a given pipeline based on a new event.<br>> <br>> A repo will have a cluster of jobs set based on pipeline.<br>> <br>> Here is the zuul configuration file for the openstack/keystone repo:<br>> http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n1832<br>> <br>> There are templates which are common across many repos, then specific<br>> jobs for the check pipeline, gate pipeline, post pipeline (which means<br>> post merge) and the experimental pipeline (which we created as a way of<br>> graduating new jobs).<br>> <br>> Here would be a good place to begin reading about zuul:<br>> http://docs.openstack.org/infra/system-config/zuul.html<br>> <br>> Thanks,<br>> Anita.<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 17<br>> Date: Tue, 09 Jun 2015 13:55:29 -0400<br>> From: Doug Hellmann <doug@doughellmann.com><br>> To: openstack-dev <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [release][oslo] oslo.middleware release<br>>  2.0.0 (liberty)<br>> Message-ID: <1433872450-sup-4921@lrrr.local><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> Excerpts from doug's message of 2015-06-09 11:14:23 -0400:<br>> > We are excited to announce the release of:<br>> > <br>> > oslo.middleware 2.0.0: Oslo Middleware library<br>> > <br>> > This release is part of the liberty release series.<br>> <br>> The changes in this version cause several projects to require manual<br>> updates to the paste.ini before/during the upgrade. We're going to<br>> revoke this version of the library and release a new one that restores<br>> the namespace package. The Oslo team will remove the package during the<br>> M cycle to give all deployers a chance to update their paste.ini files<br>> to not use the oslo namespace package.<br>> <br>> Doug<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 18<br>> Date: Tue, 9 Jun 2015 14:05:04 -0400<br>> From: Mike Bayer <mbayer@redhat.com><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x<br>> Message-ID: <55772AD0.4010204@redhat.com><br>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>> <br>> <br>> <br>> On 6/9/15 1:08 PM, Mike Bayer wrote:<br>> ><br>> > So for Openstack, we would mostly worry about code that is doing <br>> > things oddly in some unexpected way, however all the Openstack code <br>> > I've seen tends to be very ORM centric and uses the ORM very <br>> > conservatively so I don't anticipate any problems.   I would note that <br>> > some silently-/ quasi- failing use cases for query.update() and <br>> > query.delete()  now raise exceptions in 1.0.   They both emit warnings <br>> > in 0.9 but I just checked and apparently one of these warnings is only <br>> > in the as-yet unreleased 0.9.10.   I've just added an extra migration <br>> > note for one of these which appeared to be missing in the migration <br>> > document (as of this writing it should be up on RTD within an hour).<br>> ><br>> > That said, the document which tries to capture everything that might <br>> > be surprising is at <br>> > http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html.<br>> <br>> here are those:<br>> <br>> http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-query-delete-raises-if-used-with-join-select-from-from-self<br>> http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-with-synchronize-session-evaluate-raises-on-multi-table-update<br>> <br>> <br>> ><br>> ><br>> >><br>> >> Cheers,<br>> >><br>> >> Thomas Goirand (zigo)<br>> >><br>> >> __________________________________________________________________________ <br>> >><br>> >> OpenStack Development Mailing List (not for usage questions)<br>> >> Unsubscribe: <br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> ><br>> ><br>> > __________________________________________________________________________ <br>> ><br>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe: <br>> > 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: 19<br>> Date: Tue, 9 Jun 2015 18:12:26 +0000<br>> From: Jeremy Stanley <fungi@yuggoth.org><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] Please Merge patches titled "Merge Tag<br>>  ..."<br>> Message-ID: <20150609181225.GN2731@yuggoth.org><br>> Content-Type: text/plain; charset=us-ascii<br>> <br>> On 2015-06-09 09:35:55 -0400 (-0400), Monty Taylor wrote:<br>> [...]<br>> > We're going to re-run the process that generates the commits -<br>> > when the new ones come in - please merge them to make the release<br>> > team happy.<br>> [...]<br>> <br>> I've updated (after restoring if abandoned) all the pending release<br>> tag merge changes now. I've also included some helpful information<br>> in their commit messages and our automation has been improved to add<br>> the same additional detail in the future as well.<br>> <br>> https://review.openstack.org/#/q/status:open+topic:merge/release-tag,n,z<br>> <br>> Many are failing on unrelated oslo library release breakage at the<br>> moment (surfacing in grenade), but I'll recheck them once that's<br>> solved.<br>> -- <br>> Jeremy Stanley<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 20<br>> Date: Tue, 9 Jun 2015 14:19:00 -0400<br>> From: Jeff Peeler <jpeeler@redhat.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [kolla] Proposal for changing 1600UTC<br>>  meeting to 1700 UTC<br>> Message-ID: <20150609181900.GA2617@jbp-t540.redhat.com><br>> Content-Type: text/plain; charset=utf-8; format=flowed<br>> <br>> On Mon, Jun 08, 2015 at 05:15:54PM +0000, Steven Dake (stdake) wrote:<br>> >Folks,<br>> ><br>> >Several people have messaged me from EMEA timezones that 1600UTC fits <br>> >right into the middle of their family life (ferrying kids from school <br>> >and what-not) and 1700UTC while not perfect, would be a better fit <br>> >time-wise.<br>> ><br>> >For all people that intend to attend the 1600 UTC, could I get your <br>> >feedback on this thread if a change of the 1600UTC timeslot to 1700UTC <br>> >would be acceptable?  If it wouldn?t be acceptable, please chime in as <br>> >well.<br>> <br>> Both 1600 and 1700 UTC are fine for me.<br>> <br>> Jeff<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 21<br>> Date: Tue, 9 Jun 2015 11:24:14 -0700<br>> From: Zaro <zaro0508@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [infra] how to trigger a set of jenkins<br>>  jobs<br>> Message-ID:<br>>  <CABf-f+qB9BYxodmkR-Kyp=VrBa6mYbtpLcC81z53-YLrPTcioQ@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> I would encourage you to take a look at zuul but if you prefer not to use<br>> it then I believe you can also achieve your use case just using Jenkins by<br>> setting up multiple jobs with the same trigger.  The jenkins job builder<br>> tool will help you setup and manage those jobs.<br>> <br>> -Khai<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/aa3b6abc/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 22<br>> Date: Tue, 09 Jun 2015 14:25:11 -0400<br>> From: Adam Young <ayoung@redhat.com><br>> To: OpenStack Development Mailing List<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [Keystone]  Midcycle<br>> Message-ID: <55772F87.4020904@redhat.com><br>> Content-Type: text/plain; charset=utf-8; format=flowed<br>> <br>> Keystone Liberty Midcycle Meetup<br>> <br>> Time and Location<br>> <br>> When: July 15-17 (Wed-Fri)<br>> <br>> Where: Boston University, Boston, MA, USA<br>> <br>> <br>> Keystone Midcycle Wiki page:<br>> <br>> <br>> https://wiki.openstack.org/wiki/Sprints/KeystoneLibertySprint<br>> <br>> Please sign up if you are attending<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 23<br>> Date: Tue, 9 Jun 2015 21:25:53 +0300<br>> From: Joe Gordon <joe.gordon0@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [release][oslo] oslo.middleware release<br>>  2.0.0 (liberty)<br>> Message-ID:<br>>  <CAHXdxOeHzzNSbwAWor_C-TT1Lw4XLV+QX6RuTQ2Rqr0rj-H=XQ@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> On Tue, Jun 9, 2015 at 6:14 PM, <doug@doughellmann.com> wrote:<br>> <br>> > We are excited to announce the release of:<br>> ><br>> > oslo.middleware 2.0.0: Oslo Middleware library<br>> ><br>> <br>> And this broke the gate, but the fix is already working its way though the<br>> system.<br>> <br>> https://bugs.launchpad.net/grenade/+bug/1463478<br>> <br>> <br>> ><br>> > This release is part of the liberty release series.<br>> ><br>> > With source available at:<br>> ><br>> >     http://git.openstack.org/cgit/openstack/oslo.middleware<br>> ><br>> > For more details, please see the git log history below and:<br>> ><br>> >     http://launchpad.net/oslo.middleware/+milestone/2.0.0<br>> ><br>> > Please report issues through launchpad:<br>> ><br>> >     http://bugs.launchpad.net/oslo.middleware<br>> ><br>> > Changes in oslo.middleware 1.3.0..2.0.0<br>> > ---------------------------------------<br>> ><br>> > bcbfceb Remove oslo namespace package<br>> ><br>> > Diffstat (except docs and test files)<br>> > -------------------------------------<br>> ><br>> > oslo/__init__.py                  |  13 -----<br>> > oslo/middleware/__init__.py       |  28 ----------<br>> > oslo/middleware/base.py           |  13 -----<br>> > oslo/middleware/catch_errors.py   |  13 -----<br>> > oslo/middleware/correlation_id.py |  13 -----<br>> > oslo/middleware/debug.py          |  13 -----<br>> > oslo/middleware/request_id.py     |  13 -----<br>> > oslo/middleware/sizelimit.py      |  13 -----<br>> > setup.cfg                         |   4 --<br>> > 15 files changed, 429 deletions(-)<br>> ><br>> ><br>> ><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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/56e9c1f1/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 24<br>> Date: Tue, 09 Jun 2015 18:19:38 +0000<br>> From: Paul Michali <pc@michali.net><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [neutron][vpnaas][barbican] What types of<br>>  authentication to support?<br>> Message-ID:<br>>  <CA+ikoRPd6Kw6kEDMiC-SSPh+Z5cia==VEGKW6ERuYUkUJvNZ6w@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hi,<br>> <br>> There is a Request for Feature Enhancement [1] to support authentication<br>> certifications for VPNaaS IPSec site to site connections, by using<br>> Barbican, in a manner similar to what was done for LBaaS listeners.<br>> <br>> Currently, VPNaaS only supports pre-shared keys for authentication, but the<br>> reference StrongSwan implementation of VPN supports several types of<br>> authentication. [2]<br>> <br>> Looking at IPsec site-to-site connections, there are examples [3] for PSK<br>> and X.509 certificates.<br>> <br>> Should we just do X.509 certificates for now?<br>> Are there other methods that we should support?<br>> Can Barbican support such methods?<br>> <br>> The plan is to support other VPN types in the future (e.g. DM VPN), so we<br>> want to make sure this will be extendable.<br>> <br>> Suggestions/Comments/Concerns?<br>> <br>> Thanks!<br>> <br>> Paul Michali (pc_m)<br>> <br>> <br>> [1] https://bugs.launchpad.net/neutron/+bug/1459427<br>> [2] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets<br>> [3] https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples (see<br>> site-2-site)<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/c1ace4a8/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 25<br>> Date: Wed, 10 Jun 2015 05:58:46 +1200<br>> From: Robert Collins <robertc@robertcollins.net><br>> To: OpenStack Development Mailing List<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] (re)centralizing library release<br>>  management<br>> Message-ID:<br>>  <CAJ3HoZ2ZgrvEKRLnbJk+3b7K08cuyYgaRQQLTajf-8NKmcNsRg@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> I volunteer for the team.<br>> On 10 Jun 2015 5:25 am, "Doug Hellmann" <doug@doughellmann.com> wrote:<br>> <br>> > Until now we have encouraged project teams to prepare their own<br>> > library releases as new versions of projects were needed. We've<br>> > started running into a couple of problems with that, with releases<br>> > not coming often enough, or at a bad time in the release cycle, or<br>> > with version numbering not being applied consistently, or without<br>> > proper announcements. To address these issues, the release management<br>> > team is proposing to create a small team of library release managers<br>> > to handle the process around all library releases (clients,<br>> > non-application projects, middleware, Oslo libraries, etc.). This<br>> > will give us a chance to collaborate and review the version numbers<br>> > for new releases, as well as stay on top of "stale" libraries with<br>> > fixes or features that sit unreleased for a period of time. It will<br>> > also be the first step to creating an automated review process for<br>> > release tags.<br>> ><br>> > The process still needs to be worked out, but I envision it working<br>> > something like this:<br>> ><br>> > The release liaison/PTL for the project team submits a request for<br>> > a new release, including the repo name, the SHA, the series (liberty,<br>> > kilo, etc.), and the proposed version number. The release team<br>> > checks the proposed version number against the unreleased changes<br>> > up to that SHA, and then either updates it to reflect semver or<br>> > uses it as it is provided. The release team would then handle the<br>> > tag push and the resulting announcements.<br>> ><br>> > There would be a few conditions under which a new release might not<br>> > be immediately approved, but really only when the gate is wedged<br>> > and during freeze periods. The point of the change isn't to block<br>> > releases, just ensure consistency and good timing.<br>> ><br>> > We have some tools to let us look for unreleased changes, and<br>> > eventually we can set up a recurring job to build that report so<br>> > we can propose releases to project teams with a large release<br>> > backlog. That will likely come later, though.<br>> ><br>> > We can also pre-announce proposed releases if folks find that useful.<br>> ><br>> > We will need a small number of volunteers to join this team, and<br>> > start building the required expertise in understanding the overall<br>> > state of the project, and in semantic versioning. We do not necessarily<br>> > want a liaison from every project -- think of this as the proto-team<br>> > for the group that eventually has core reviewer rights on the release<br>> > automation repository.<br>> ><br>> > Doug<br>> ><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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150610/457805c6/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 26<br>> Date: Tue, 09 Jun 2015 14:08:06 -0400<br>> From: Jay Pipes <jaypipes@gmail.com><br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> Message-ID: <55772B86.6000600@gmail.com><br>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>> <br>> On 06/08/2015 05:10 PM, Sean M. Collins wrote:<br>> > Hi,<br>> ><br>> > Within each API extension in the neutron tree, there is a method:<br>> ><br>> >      def get_namespace(cls):<br>> ><br>> > Which returns a string, containing a URL.<br>> <br>> <snip><br>> <br>> > I believe that they all 404.<br>> ><br>> > A dumb question to start, then progressively smarter questions:<br>> ><br>> > * What is the purpose of the URLs?<br>> <br>> They are the sad detritus left from XML support.<br>> <br>> > * Should the URL point to documentation?<br>> <br>> Perhaps.<br>> <br>> > * What shall we do about the actual URLs 404'ing?<br>> <br>> Honestly, I'd prefer the namespaces just be removed, but I'm not sure <br>> what Neutron's position is about XML and the REST API...<br>> <br>> Best,<br>> -jay<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 27<br>> Date: Tue, 9 Jun 2015 21:24:06 +0300<br>> From: Joe Gordon <joe.gordon0@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x<br>> Message-ID:<br>>  <CAHXdxOeLYrQzuoJzw6t=mJZNvU3v6baNxZ+uXD7-4USyBaRCEQ@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer <mbayer@redhat.com> wrote:<br>> <br>> ><br>> ><br>> > On 6/9/15 9:26 AM, Thomas Goirand wrote:<br>> ><br>> >> Hi,<br>> >><br>> >> The python-sqlalchemy package has been uploaded to Debian Experimental,<br>> >> and is about to be uploaded to Debian Unstable. So I wonder what's the<br>> >> state of the project regarding upgrading SQLA.<br>> >><br>> >> Maybe Mike can tell what kind of issue we may run into? How much work<br>> >> will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be<br>> >> compatible with both 9.x and 1.x (which would be the best way forward)?<br>> >><br>> ><br>> > The short answer is that there are no supported use cases that have been<br>> > intentionally changed in any backwards incompatible way in 1.0 and all<br>> > Openstack code should be able to accommodate from 0.9.x -> 1.0.x without<br>> > any change.<br>> ><br>> <br>> Just posted a patch to test this out:  https://review.openstack.org/189847<br>> <br>> <br>> ><br>> > I run SQLAlchemy's master against a small subset of Openstack tests<br>> > continuously, including Nova DB API, Keystone, all of oslo.db and Neutron's<br>> > migration tests, and there was nothing that needed changing as we went<br>> > along.   I've also run devstack against SQLAlchemy 1.0 without problems<br>> > though I don't have a lot of openstack-user-fu so I didn't stress test it<br>> > too much at that level.<br>> ><br>> > It's my expectation that nothing in Openstack should have to change to<br>> > work with SQLAlchemy 1.0 - the kinds of things that change tend to be<br>> > subtle things related to odd use cases and newer features, usually along<br>> > the lines of applications that may have been relying upon some behavior<br>> > that was undefined, that then changes it's behavior in some way.<br>> ><br>> > An example is that we had a user who was running a query of the form<br>> > "session.query(SomeObject).with_parent(SomeParent(id=None))", e.g. trying<br>> > to find objects that *didn't* have a parent by using a transient "Parent"<br>> > with "id=None" - totally unexpected way of doing that, and it wasn't even<br>> > working for that user as it came up with an "= NULL" comparison that isn't<br>> > even right, *but* when SQLA 1.0 came around it started leaking an internal<br>> > symbol into the query, and *then* it became noticeable.  That's the kind of<br>> > thing that "breaks" with new SQLAlchemy versions these days.   We had a lot<br>> > of those this time around, and the vast majority of them were logged as<br>> > regressions which were fixed and added to testing.   You can see those by<br>> > browsing versions 1.0.1 -> 1.0.5 at<br>> > http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html.<br>> ><br>> > We never intentionally make *any* backwards incompatible change in just<br>> > one major version without warnings being emitted in the previous version,<br>> > and the warnings usually involve urging the user to set a flag to "use the<br>> > old way" if they're going to upgrade; that is, we at least always try to<br>> > add flags to keep an old behavior in place if at all possible.   I've not<br>> > seen anything in Openstack that would be sensitive to this kind of issue<br>> > for 1.0.<br>> ><br>> > So for Openstack, we would mostly worry about code that is doing things<br>> > oddly in some unexpected way, however all the Openstack code I've seen<br>> > tends to be very ORM centric and uses the ORM very conservatively so I<br>> > don't anticipate any problems.   I would note that some silently-/ quasi-<br>> > failing use cases for query.update() and query.delete()  now raise<br>> > exceptions in 1.0.   They both emit warnings in 0.9 but I just checked and<br>> > apparently one of these warnings is only in the as-yet unreleased 0.9.10.<br>> >  I've just added an extra migration note for one of these which appeared to<br>> > be missing in the migration document (as of this writing it should be up on<br>> > RTD within an hour).<br>> ><br>> > That said, the document which tries to capture everything that might be<br>> > surprising is at<br>> > http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html.<br>> ><br>> ><br>> ><br>> ><br>> >> Cheers,<br>> >><br>> >> Thomas Goirand (zigo)<br>> >><br>> >> __________________________________________________________________________<br>> >> OpenStack Development Mailing List (not for usage questions)<br>> >> Unsubscribe:<br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> >><br>> ><br>> ><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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/5e82b1af/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 28<br>> Date: Tue, 9 Jun 2015 19:00:30 +0000<br>> From: Brandon Logan <brandon.logan@RACKSPACE.COM><br>> To: "openstack-dev@lists.openstack.org"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> Message-ID: <1433876433033.24130@RACKSPACE.COM><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> I believe XML support got removed from the API last cycle.<br>> ________________________________________<br>> From: Jay Pipes <jaypipes@gmail.com><br>> Sent: Tuesday, June 9, 2015 1:08 PM<br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> <br>> On 06/08/2015 05:10 PM, Sean M. Collins wrote:<br>> > Hi,<br>> ><br>> > Within each API extension in the neutron tree, there is a method:<br>> ><br>> >      def get_namespace(cls):<br>> ><br>> > Which returns a string, containing a URL.<br>> <br>> <snip><br>> <br>> > I believe that they all 404.<br>> ><br>> > A dumb question to start, then progressively smarter questions:<br>> ><br>> > * What is the purpose of the URLs?<br>> <br>> They are the sad detritus left from XML support.<br>> <br>> > * Should the URL point to documentation?<br>> <br>> Perhaps.<br>> <br>> > * What shall we do about the actual URLs 404'ing?<br>> <br>> Honestly, I'd prefer the namespaces just be removed, but I'm not sure<br>> what Neutron's position is about XML and the REST API...<br>> <br>> Best,<br>> -jay<br>> <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>> Message: 29<br>> Date: Tue, 9 Jun 2015 19:02:51 +0000<br>> From: "Steven Dake (stdake)" <stdake@cisco.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [kolla] Scheduling for a mid-cycle - doodle<br>>  poll inside<br>> Message-ID: <D19C86A5.9F92%stdake@cisco.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> This is an open invitation to Operators that have an interest in contributing to the Kolla design around deployment to participate in a 2 day design focused midcycle summit.  The hours will run from 10:00 AM to 5:00 PM PST and  the location will be in San Jose, CA in the US.  The two days will be scheduled together.<br>> <br>> Please record all days you can attend so I can schedule the best possible coverage for the most individuals.<br>> <br>> The doodle poll is located here:<br>> <br>> http://doodle.com/su62amktdrp5mrez<br>> <br>> I?ll keep the poll open for a one week period until June 17th.<br>> <br>> Regards<br>> -steve<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/0aab546d/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 30<br>> Date: Tue, 9 Jun 2015 20:10:58 +0100<br>> From: Simon McCartney <simon@mccartney.ie><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [infra] how to trigger a set of jenkins<br>>  jobs<br>> Message-ID:<br>>  <CAGO12aTw==3bckiqAuBCiHFLh_u2PokPD2NmBjz7nvOFxps_Sw@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> ><br>> > The origin concept of jenkins is "one trigger one job". For example, the<br>> > job "neutron-unit-test-py27" could respond a new change set from neutron<br>> > upstream. But the truth is that a gerrit event trigger a set of jenkins<br>> > jobs: py27-unittest, pep8-check, and many dsvm jobs...<br>> ><br>> > How can I configure my jenkins like this?<br>> ><br>> <br>> We use the<br>> https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin<br>> plugin to do this, we have a master jenkins job that fires on some trigger<br>> (git repo change etc), and then fires off a set of sub jobs that we want<br>> executed in response to that.  (we use this via the JJB macro:<br>> http://docs.openstack.org/infra/jenkins-job-builder/builders.html#builders.trigger-builds<br>> - if you're using JJB to maintain your jobs)<br>> <br>> HTH,<br>> <br>> Simon.<br>> -- <br>> Simon McCartney<br>> E: simon@mccartney.ie<br>> M: +44 7710 836 915<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/71b93b55/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 31<br>> Date: Tue, 9 Jun 2015 12:33:39 -0700<br>> From: Kevin Benton <blak111@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> Message-ID:<br>>  <CAO_F6JMtOHL_UBkFvJ+z1OuJgKUga9JPKwYpJbHTJ-1AKwZj9Q@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> I heard rumors that Oracle was going to introduce XML-as-a-service to<br>> OpenStack to make it enterprise-grade. If that's the case, we'll be ahead<br>> of everyone with our namespaces.<br>> On Jun 9, 2015 12:04 PM, "Brandon Logan" <brandon.logan@rackspace.com><br>> wrote:<br>> <br>> > I believe XML support got removed from the API last cycle.<br>> > ________________________________________<br>> > From: Jay Pipes <jaypipes@gmail.com><br>> > Sent: Tuesday, June 9, 2015 1:08 PM<br>> > To: openstack-dev@lists.openstack.org<br>> > Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> ><br>> > On 06/08/2015 05:10 PM, Sean M. Collins wrote:<br>> > > Hi,<br>> > ><br>> > > Within each API extension in the neutron tree, there is a method:<br>> > ><br>> > >      def get_namespace(cls):<br>> > ><br>> > > Which returns a string, containing a URL.<br>> ><br>> > <snip><br>> ><br>> > > I believe that they all 404.<br>> > ><br>> > > A dumb question to start, then progressively smarter questions:<br>> > ><br>> > > * What is the purpose of the URLs?<br>> ><br>> > They are the sad detritus left from XML support.<br>> ><br>> > > * Should the URL point to documentation?<br>> ><br>> > Perhaps.<br>> ><br>> > > * What shall we do about the actual URLs 404'ing?<br>> ><br>> > Honestly, I'd prefer the namespaces just be removed, but I'm not sure<br>> > what Neutron's position is about XML and the REST API...<br>> ><br>> > Best,<br>> > -jay<br>> ><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>> > 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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/bb7349b7/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 32<br>> Date: Tue, 9 Jun 2015 13:33:57 -0600<br>> From: Carl Baldwin <carl@ecbaldwin.net><br>> To: OpenStack Development Mailing List<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] Fwd:  [neutron] - L3 scope-aware security<br>>  groups<br>> Message-ID:<br>>  <CALiLy7rJe4Dh0ik2D=E+04s13u_ijaDPQ11WBKc2JESG_UzEcw@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton <blak111@gmail.com> wrote:<br>> > There is a bug in security groups here:<br>> > https://bugs.launchpad.net/neutron/+bug/1359523<br>> ><br>> > In the example scenario, it's caused by conntrack zones not being<br>> isolated.<br>> > But it also applies to the following scenario that can't be solved by<br>> zones:<br>> ><br>> > create two networks with same 10.0.0.0/24<br>> > create port1 in SG1 on net1 with IP 10.0.0.1<br>> > create port2 in SG1 on net2 with IP 10.0.0.2<br>> > create port3 in SG2 on net1 with IP 10.0.0.2<br>> > create port4 in SG2 on net2 with IP 10.0.0.1<br>> <br>> This sounds like a different bug than 1359523. It isn't what was described<br>> in the bug report and has a different underlying cause. While it looks<br>> similar on the surface, could we open up a new bug to track this?  Just<br>> curious has anyone hit this in the wild or is this totally contrived?<br>> <br>> My first reaction to this is that if you set this up like this, you deserve<br>> it.  Maybe we just advise that people plan to avoid scenarios that<br>> intersect multiple security groups across disparate L2 networks using<br>> overlapping IP address space.  Don't use overlapping subnets.  Or, if you<br>> do, don't use the same security group across them.  But, that is just a cop<br>> out if we haven't had a discussion.<br>> <br>> Using address scopes will prevent any overlap and fix this situation in the<br>> following way.  I think this is what Kevin had in mind:<br>> <br>> create two networks with same 10.0.0.0/24 allocating the subnets from an<br>> address pool.  They must be allocated from different subnet scopes.  We<br>> know because if they were the same scope, overlap wouldn't be allowed.  A<br>> fundamental design feature of address scopes is that address overlap is<br>> prevented within the scope.<br>> <br>>   Net1 has address scope a and net2 has address scope b.   All the subnets<br>> on a network from the same address family are required to be from the same<br>> pool.  Hence, they'll be in the same scope.<br>> <br>>   create port1 in SG1 on net1 with IP 10.0.0.1.  Has address scope a<br>>   create port2 in SG1 on net2 with IP 10.0.0.2.  Has address scope b<br>>   create port3 in SG2 on net1 with IP 10.0.0.2.  Has address scope a<br>>   create port4 in SG2 on net2 with IP 10.0.0.1.  Has address scope b<br>> <br>> The scope names are arbitrary and contrived but we know that port1 and<br>> port3 must be in the same scope because they are on the same network.  We<br>> also know that a != b because the same scope wouldn't allow the overlap.<br>> <br>> > port1 can communicate with port3 because of the allow rule for port2's IP<br>> > port2 can communicate with port4 because of the allow rule for port1's IP<br>> <br>> These would be prevented if the security group code notices that port1 and<br>> port2 are not in the same scope and therefore will never be able to<br>> communicate without some sort of NAT in between.  It should leave out the<br>> allow rules because of this.<br>> <br>> Same for port3 and port4 in the other SG.<br>> <br>> > The solution will require the security groups processing code to<br>> understand<br>> > that a member of a security group is not actually reachable by another<br>> > member and skip the allow rule for that member.<br>> <br>> I said the same thing just with a little more specificity and referring to<br>> the example.<br>> <br>> > With the current state of things, it will take a tone of kludgy code to<br>> > check for routers and router interfaces to see if two IPs can communicate<br>> > without NAT. However, if we end up with the concept of address-scopes, it<br>> > just becomes a simple address scope comparison.<br>> <br>> I'm not inclined to invest a lot of effort in to this.  I don't see it as a<br>> big security hole.  Is there a way to exploit this that I cannot see?  I'm<br>> still inclined to say that we should come up with some kind of advise for<br>> how to manage SGs and networks to avoid it.<br>> <br>> > Implement address scopes.<br>> <br>> I will. Stay tuned.  I did not, however, include any kind of integration<br>> with security groups with my address scopes spec.  I don't think I should<br>> necessarily stop everything to include it either.  I still tend to think<br>> that this example is a bit contrived which is why I've asked if this was<br>> hit in the wild.<br>> <br>> You should keep in mind that address scopes will not be forced on anyone.<br>> You will get the same thing as today if you continue to make all the same<br>> API calls to set it up. Address scopes will only come in to play if you use<br>> subnet pools. If you don't use subnet pools, you can still create<br>> overlapping address ranges.  So, we can make security groups address scope<br>> aware but it won't fix the problem for existing models.<br>> <br>> Carl<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/acdc934a/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 33<br>> Date: Tue, 09 Jun 2015 12:38:55 -0700<br>> From: Cody Herriges <cody@puppetlabs.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [puppet] Move to rspec-puppet 2.2.0<br>> Message-ID: <557740CF.8020308@puppetlabs.com><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> Seemingly simple proposition of moving from rspec-puppet 2.1.0 to 2.2.0<br>> so as to address the issue of helper library loading that is shipped as<br>> part of a few of our modules.  In my specific case, puppet-vswitch's<br>> puppetx library directory and its use by puppet-neutron.  This is part<br>> of the effort to get all the modules passing tests on Puppet 4.<br>> <br>> The upstream rspec-puppet commit:<br>> https://github.com/rodjek/rspec-puppet/commit/d4278834d5236deb497b84fbd937bc33e6a717a3<br>> <br>> puppet-modulesync-configs: https://review.openstack.org/189886<br>> <br>> I already shipped for review, a msync based update to all managed module<br>> based on the above review on puppet-modulesync-configs.  If there are no<br>> objections to this, I'll clean up them and get them passing.  In the<br>> mean time I'll go through and just mark them all WIP.<br>> <br>> -- <br>> Cody<br>> <br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: signature.asc<br>> Type: application/pgp-signature<br>> Size: 931 bytes<br>> Desc: OpenPGP digital signature<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/c56a607e/attachment-0001.pgp><br>> <br>> ------------------------------<br>> <br>> Message: 34<br>> Date: Tue, 09 Jun 2015 19:43:07 +0000<br>> From: Michael Krotscheck <krotscheck@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [javascript] Linters<br>> Message-ID:<br>>  <CABM65as_e5F5iOcq39TtQTHHXSFe1uZqk7M5MdfL8U-eCCu7_A@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> The more I think about this, the more I think my ideas are dumb.<br>> <br>> John Papa has very opinionated guides on how an _angular_ application<br>> should be structured. Openstack's linting must be framework agnostic,<br>> because we can't predict which frameworks may or may not be used. For<br>> example, there is a good case for a framework-agnostic API library for<br>> [Insert API Here].<br>> <br>> So, let's just start with the Google Style Guidelines, and let projects use<br>> plugins (like eslint-angular) to support additional project guidelines.<br>> <br>> Michael<br>> <br>> On Tue, Jun 9, 2015 at 9:01 AM Michael Krotscheck <krotscheck@gmail.com><br>> wrote:<br>> <br>> > Well, it looks like everyone has disqualified jslint and jshint, so let's<br>> > just make a decision there and remove them from the running. Unless I hear<br>> > a compelling reason to use something that has the infamous "do no evil"<br>> > license in it, let's dump it.<br>> ><br>> > The John Papa styles seem sane, and though I disagree with them, I'd be ok<br>> > using them. Putting everything in a closure is an old standard that has<br>> > usually just annoyed me, since it's one of those things about javascript<br>> > that _shouldn't_ have to be explicit, but no language is perfect ;). The<br>> > existing eslint stylesheets that exist in StoryBoard and others were<br>> > written with PEP8 in mind, in order to facilitate readability between our<br>> > languages, however I am also a strong believer in treating JavaScript on<br>> > equal terms with other languages. Also, John papa seems to have more<br>> > opinions about angular apps than javascript in general, so I propose this<br>> > rule for OpenStack going forward:<br>> ><br>> > 1- If the John Papa rules have an opinion, use that.<br>> > 2- Otherwise, use pep8 (where applicable).<br>> > 3- Otherwise, check to see if there's a thing in hacking.<br>> > 4- If it's in none of those, we'll address it on a case by case basis.<br>> ><br>> > The main reasons for this is that I simply do not want to have an argument<br>> > about spaces vs. tabs. The arguments about PEP8 have already been had, and<br>> > the benefits of a language-wide enforced style are simple: We can argue<br>> > about more important things! :). Let's assume a week of commentary on the<br>> > above.<br>> ><br>> > As for how this is synchronized, a brief discussion in the infra channel<br>> > proposed that we put global javascript requirements in the<br>> > global-requirements repo, and then update the update.py script in that repo<br>> > to also handle bower.json and package.json. Then, if we build an<br>> > eslint/jscs plugin similar to our hacking rules, we can just update that<br>> > when we want to modify the linting rules. Any objections?<br>> ><br>> > With regards to JSCS vs. Eslint, I feel that we actually have to use both<br>> > to decide which is better: Once we set up the rules side by side and try to<br>> > apply them against a project, a clear winner will emerge. Does anyone want<br>> > to volunteer to put together a spreadsheet of all the rules from John Papa<br>> > and pep8 that we'd like to enforce, and the appropriate rule in eslint<br>> > and/or jscs that applies?<br>> ><br>> > Michael<br>> ><br>> > On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S <travis.tripp@hp.com><br>> > wrote:<br>> ><br>> >> We?ve adopted the John Papa style guide for Angular in horizon [0]. On<br>> >> cursory inspection ES lint seems to have an angular specific plugin [1]<br>> >> that could be very useful to us, but we?d need to evaluate it in depth. It<br>> >> looks like there was some discussion on the style guide on this not too<br>> >> long ago [2]. The jscs rules we have [3] are very generic code formatting<br>> >> type rules that are helpful, but don't really provide any angular specific<br>> >> help. Here are the jshint rules [4]. It would be quite nice to put all<br>> >> this goodness across tools into a single tool configuration if possible.<br>> >><br>> >> [0]<br>> >><br>> >> http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty<br>> >> le-guide<br>> >> <http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide><br>> >> [1] https://www.npmjs.com/package/eslint-plugin-angular<br>> >> [2] https://github.com/johnpapa/angular-styleguide/issues/194<br>> >> [3] https://github.com/openstack/horizon/blob/master/.jscsrc<br>> >> [4] https://github.com/openstack/horizon/blob/master/.jshintrc<br>> >><br>> >> On 6/8/15, 9:59 PM, "gustavo panizzo (gfa)" <gfa@zumbi.com.ar> wrote:<br>> >><br>> >> ><br>> >> ><br>> >> >On 2015-06-06 03:26, Michael Krotscheck wrote:<br>> >> >> Right now, there are several JS linters in use in OpenStack: JSHint,<br>> >> >> JSCS, and Eslint. I really would like to only use one of them, so that<br>> >> I<br>> >> >> can figure out how to sanely share the configuration between projects.<br>> >> >><br>> >> >> Can all those who have a strong opinion please stand up and state their<br>> >> >> opinions?<br>> >> ><br>> >> >what about https://bitbucket.org/dcs/jsmin/ it's license is free<br>> >> ><br>> >> ><br>> >> >--<br>> >> >1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333<br>> >> ><br>> >> >keybase: http://keybase.io/gfa<br>> >> ><br>> >><br>> >> >__________________________________________________________________________<br>> >> >OpenStack Development Mailing List (not for usage questions)<br>> >> >Unsubscribe:<br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> >><br>> >><br>> >> __________________________________________________________________________<br>> >> OpenStack Development Mailing List (not for usage questions)<br>> >> Unsubscribe:<br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> >><br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/caa45a13/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 35<br>> Date: Tue, 09 Jun 2015 13:01:08 -0700<br>> From: corvus@inaugust.com (James E. Blair)<br>> To: OpenStack Development Mailing List<br>>  <openstack-dev@lists.openstack.org><br>> Cc: openstack-infra@lists.openstack.org<br>> Subject: [openstack-dev] Gerrit downtime on Friday 2015-06-12 at 22:00<br>>  UTC<br>> Message-ID: <87mw08d52z.fsf@meyer.lemoncheese.net><br>> Content-Type: text/plain<br>> <br>> On Friday, June 12 at 22:00 UTC Gerrit will be unavailable for about 30<br>> minutes while we rename some projects.<br>> <br>> Existing reviews, project watches, etc, should all be carried<br>> over. Currently, we plan on renaming the following projects:<br>> <br>>     stackforge/mistral -> openstack/mistral<br>>     stackforge/ironic-discoverd -> openstack/ironic-inspector<br>>     stackforge/fuel-plugin-group-based-policy -> stackforge-attic/fuel-plugin-group-based-policy<br>>     stackforge/fuel-plugin-external-nfs -> stackforge-attic/fuel-plugin-external-nfs<br>>     stackforge/zvm-driver -> stackforge-attic/zvm-driver<br>>     stackforge/octavia -> openstack/octavia<br>>     stackforge/networking-midonet -> openstack/networking-midonet<br>>     stackforge/networking-odl -> openstack/networking-odl<br>>     stackforge/networking-ofagent -> openstack/networking-ofagent<br>>     stackforge/networking-ovn -> openstack/networking-ovn<br>>     stackforge/networking-l2gw -> openstack/networking-l2gw<br>>     stackforge/networking-cisco -> openstack/networking-cisco<br>>     stackforge/cookbook-openstack-bare-metal -> openstack/cookbook-openstack-bare-metal<br>>     stackforge/cookbook-openstack-block-storage -> openstack/cookbook-openstack-block-storage<br>>     stackforge/cookbook-openstack-compute -> openstack/cookbook-openstack-compute<br>>     stackforge/cookbook-openstack-dashboard -> openstack/cookbook-openstack-dashboard<br>>     stackforge/cookbook-openstack-data-processing -> openstack/cookbook-openstack-data-processing<br>>     stackforge/cookbook-openstack-database -> openstack/cookbook-openstack-database<br>>     stackforge/cookbook-openstack-identity -> openstack/cookbook-openstack-identity<br>>     stackforge/cookbook-openstack-image -> openstack/cookbook-openstack-image<br>>     stackforge/cookbook-openstack-network -> openstack/cookbook-openstack-network<br>>     stackforge/cookbook-openstack-object-storage -> openstack/cookbook-openstack-object-storage<br>>     stackforge/cookbook-openstack-orchestration -> openstack/cookbook-openstack-orchestration<br>>     stackforge/cookbook-openstack-telemetry -> openstack/cookbook-openstack-telemetry<br>>     stackforge/openstack-chef-repo -> openstack/openstack-chef-repo<br>>     stackforge/openstack-chef-specs -> openstack/openstack-chef-specs<br>>     stackforge/cookbook-pacemaker -> stackforge-attic/cookbook-pacemaker<br>>     stackforge/vmware-nsx -> openstack/vmware-nsx<br>> <br>> This list is subject to change.<br>> <br>> If you have any questions about the maintenance, please reply here or<br>> contact us in #openstack-infra on Freenode.<br>> <br>> -Jim<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 36<br>> Date: Tue, 09 Jun 2015 15:56:51 -0400<br>> From: michael mccune <msm@redhat.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [sahara] Migrating to use Keystone Session<br>>  objects<br>> Message-ID: <55774503.3010209@redhat.com><br>> Content-Type: text/plain; charset=utf-8; format=flowed<br>> <br>> hi saharans,<br>> <br>> i have been doing some research into converting our current <br>> authentication to use the Keystone Session objects[1] instead of the <br>> various methods that are now used with the openstack clients.<br>> <br>> this effort has some wide-ranging implications as we will need to <br>> convert our usage of openstack clients to accept a new workflow. as part <br>> of this we might need to change our Context object to retain a Session <br>> instead of the current authentication information. it may even be <br>> possible to greatly simplify the information that the Context object <br>> contains.<br>> <br>> i think this work can logically be broken into several parts, the first <br>> part would involve changing the creation of Keystone Client objects to <br>> be generated from a Session. after this change, the next step would <br>> involve changing the various openstack client objects that are in use to <br>> be created from Sessions instead.<br>> <br>> i am working on a spec for this but i have heard from Sergey Reshetnyak <br>> during the IRC meeting that he and Andrey Pavlov had interest in this <br>> topic as well. i wanted to start something on the mailing list for us to <br>> discuss the progress of this effort. so, my questions are:<br>> <br>> should i continue to draft a spec surrounding this, or is Andrey looking <br>> into a spec as well?<br>> <br>> assuming i continue to draft a spec, would Andrey, or anyone else, want <br>> to be added as contributors?<br>> <br>> alternatively, would someone else like to take the lead on the <br>> implementation?<br>> <br>> if we have multiple people working on this it might be easier to break <br>> up all the client work that needs to be done. i think we will need to <br>> clearly organize the effort and this is where the spec comes in.<br>> <br>> <br>> thanks,<br>> mike<br>> <br>> [1]: <br>> http://docs.openstack.org/developer/python-keystoneclient/using-sessions.html<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 37<br>> Date: Tue, 9 Jun 2015 22:58:15 +0300<br>> From: Kirill Zaitsev <kzaitsev@mirantis.com><br>> To: openstack-dev@lists.openstack.org<br>> Subject: [openstack-dev] [murano] shellcheck all .sh scripts in<br>>  murano-deployment<br>> Message-ID: <etPan.55774557.53358796.154@TefMBPr.local><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Folks, I?ve got another proposal, mainly to the guys, who deal with CI and test jobs daily.<br>> <br>> What would you say about adding a job to murano-deployment, that would launch shellcheck?http://www.shellcheck.net/about.html?against all .sh files??<br>> <br>> I use it, when reviewing .sh scripts (well, actually my vim does it for me =P) and although It has some excessive checks I find it quite useful.<br>> <br>> We could also add a similar job to murano-apps, since they use shell scripts quite often.<br>> <br>> Any objections to this idea?<br>> <br>> <br>> --?<br>> Kirill Zaitsev<br>> Murano team<br>> Software Engineer<br>> Mirantis, Inc<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/edb15813/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 38<br>> Date: Tue, 9 Jun 2015 20:03:30 +0000<br>> From: "Stafford, John Richard" <john.stafford@hp.com><br>> To: "openstack-dev@lists.openstack.org"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [Ironic] Mid-Cycle Sprint<br>> Message-ID:<br>>  <9BA78B4960EB824289E54FED346CDB6D050D5A9C@G4W3221.americas.hpqcorp.net><br>>  <br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Hello Ironicers!<br>> <br>> We are still running a poll for our proposed Mid-Cycle Sprint in Seattle. So far we have six [6] yes votes for Aug 12-14, one [1] proposed alternate date of Aug 5-7 and one [1] proposed alternate date of Aug 19-21.<br>> <br>> Please take a minute to fill out the poll here: http://goo.gl/forms/RJvq0uqfSD<br>> <br>> Cheers!<br>> John Stafford<br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/066a476f/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 39<br>> Date: Tue, 09 Jun 2015 16:08:16 -0400<br>> From: Doug Hellmann <doug@doughellmann.com><br>> To: openstack-dev <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] (re)centralizing library release<br>>  management<br>> Message-ID: <1433880411-sup-5098@lrrr.local><br>> Content-Type: text/plain; charset=UTF-8<br>> <br>> Excerpts from Doug Hellmann's message of 2015-06-09 13:25:26 -0400:<br>> > Until now we have encouraged project teams to prepare their own<br>> > library releases as new versions of projects were needed. We've<br>> > started running into a couple of problems with that, with releases<br>> > not coming often enough, or at a bad time in the release cycle, or<br>> > with version numbering not being applied consistently, or without<br>> > proper announcements. To address these issues, the release management<br>> > team is proposing to create a small team of library release managers<br>> > to handle the process around all library releases (clients,<br>> > non-application projects, middleware, Oslo libraries, etc.). This<br>> > will give us a chance to collaborate and review the version numbers<br>> > for new releases, as well as stay on top of "stale" libraries with<br>> > fixes or features that sit unreleased for a period of time. It will<br>> > also be the first step to creating an automated review process for<br>> > release tags.<br>> > <br>> > The process still needs to be worked out, but I envision it working<br>> > something like this:<br>> > <br>> > The release liaison/PTL for the project team submits a request for<br>> > a new release, including the repo name, the SHA, the series (liberty,<br>> > kilo, etc.), and the proposed version number. The release team<br>> > checks the proposed version number against the unreleased changes<br>> > up to that SHA, and then either updates it to reflect semver or<br>> > uses it as it is provided. The release team would then handle the<br>> > tag push and the resulting announcements.<br>> > <br>> > There would be a few conditions under which a new release might not<br>> > be immediately approved, but really only when the gate is wedged<br>> > and during freeze periods. The point of the change isn't to block<br>> > releases, just ensure consistency and good timing.<br>> > <br>> > We have some tools to let us look for unreleased changes, and<br>> > eventually we can set up a recurring job to build that report so<br>> > we can propose releases to project teams with a large release<br>> > backlog. That will likely come later, though.<br>> > <br>> > We can also pre-announce proposed releases if folks find that useful.<br>> > <br>> > We will need a small number of volunteers to join this team, and<br>> > start building the required expertise in understanding the overall<br>> > state of the project, and in semantic versioning. We do not necessarily<br>> > want a liaison from every project -- think of this as the proto-team<br>> > for the group that eventually has core reviewer rights on the release<br>> > automation repository.<br>> <br>> The change to update the ACLs is https://review.openstack.org/189856<br>> <br>> I would appreciate a review to ensure I've not missed any library-like<br>> things, and so that all projects understand which repositories this<br>> affects.<br>> <br>> Doug<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 40<br>> Date: Tue, 9 Jun 2015 16:10:18 -0400<br>> From: Ruby Loo <rlooyahoo@gmail.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] [Ironic] subteam status report<br>> Message-ID:<br>>  <CA+5K_1EO5U-8Bg7FX_xjfa9=8qAEy7RdNuxkYqRH4jtZx6MA4Q@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hi,<br>> <br>> Following is the subteam report for Ironic. As usual, this is pulled<br>> directly from the Ironic whiteboard[0] and formatted.<br>> <br>> Drivers<br>> ======<br>> <br>> iLO (wanyen)<br>> ------------------<br>> <br>> 3rd-party CI is  ready but need to setup isloated network  environment to<br>> roll it out<br>> <br>> Several specs are under review:<br>> - UEFI secure boot for pxe-ilo driver<br>> https://review.openstack.org/#/c/174295/<br>> -  Generic RAID configuration https://review.openstack.org/#/c/173214/  has<br>> two +2 but still needs workflow approval.<br>> -  in-band RAD config https://review.openstack.org/#/c/173218/<br>> - zapping support for iLO drivers https://review.openstack.org/#/c/145404/<br>> - capabilitites should accept value as dictionary<br>> https://review.openstack.org/#/c/182934/<br>> <br>> <br>> iRMC (naohirot)<br>> ---------------------<br>> <br>> https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z<br>> <br>> Status: Reactive (solicit for core team's review and approval)<br>> - iRMC Virtual Media Deploy Driver<br>>     - Deploy Driver Base patch which implemented:<br>>         - bp/irmc-virtualmedia-deploy-driver<br>>         - bp/non-glance-image-refs<br>>         - bp/automate-uefi-bios-iso-creation<br>> <br>>     - On top of the base, following up patches implemented:<br>>         - bp/local-boot-support-with-partition-images<br>>         - bp/whole-disk-image-support<br>>         - bp/ipa-as-default-ramdisk<br>> <br>> Status: Active<br>> - Enhance Power Interface for Soft Reboot and NMI<br>>     - bp/enhance-power-interface-for-soft-reboot-and-nmi<br>> - The next work item currently iRMC team is investigating:<br>>     - bp/ironic-node-properties-discovery<br>> <br>> ........<br>> <br>> Until next week,<br>> --ruby<br>> <br>> [0] https://etherpad.openstack.org/p/IronicWhiteBoard<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/0bd23af9/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 41<br>> Date: Tue, 9 Jun 2015 21:12:07 +0100<br>> From: Salvatore Orlando <sorlando@nicira.com><br>> To: "OpenStack Development Mailing List (not for usage questions)"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> Message-ID:<br>>  <CAGR=i3gXrML2z7O4T61Nmuarvndr6S=8Q0kM=0_e_PLepM40Zw@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Jay is pretty much right.<br>> <br>> In Neutron's case it is even more trivial. Somebody copied the extension<br>> manager from Nova, and a sort of extension interface with this namespace.<br>> And every neutron developer, including me felt compelled to filling that up<br>> with something that resembled an XML namespace URI (which often resolve to<br>> nowhere anyway).<br>> <br>> I think a patch for blanking out those namespace is a great low hanging<br>> fruit for new contributors.<br>> But on the other hand I'm pretty sure Kevin is wiping them out as a part of<br>> the Pecan refactor.<br>> <br>> Salvatore<br>> <br>> On 9 June 2015 at 20:33, Kevin Benton <blak111@gmail.com> wrote:<br>> <br>> > I heard rumors that Oracle was going to introduce XML-as-a-service to<br>> > OpenStack to make it enterprise-grade. If that's the case, we'll be ahead<br>> > of everyone with our namespaces.<br>> > On Jun 9, 2015 12:04 PM, "Brandon Logan" <brandon.logan@rackspace.com><br>> > wrote:<br>> ><br>> >> I believe XML support got removed from the API last cycle.<br>> >> ________________________________________<br>> >> From: Jay Pipes <jaypipes@gmail.com><br>> >> Sent: Tuesday, June 9, 2015 1:08 PM<br>> >> To: openstack-dev@lists.openstack.org<br>> >> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs<br>> >><br>> >> On 06/08/2015 05:10 PM, Sean M. Collins wrote:<br>> >> > Hi,<br>> >> ><br>> >> > Within each API extension in the neutron tree, there is a method:<br>> >> ><br>> >> >      def get_namespace(cls):<br>> >> ><br>> >> > Which returns a string, containing a URL.<br>> >><br>> >> <snip><br>> >><br>> >> > I believe that they all 404.<br>> >> ><br>> >> > A dumb question to start, then progressively smarter questions:<br>> >> ><br>> >> > * What is the purpose of the URLs?<br>> >><br>> >> They are the sad detritus left from XML support.<br>> >><br>> >> > * Should the URL point to documentation?<br>> >><br>> >> Perhaps.<br>> >><br>> >> > * What shall we do about the actual URLs 404'ing?<br>> >><br>> >> Honestly, I'd prefer the namespaces just be removed, but I'm not sure<br>> >> what Neutron's position is about XML and the REST API...<br>> >><br>> >> Best,<br>> >> -jay<br>> >><br>> >> __________________________________________________________________________<br>> >> OpenStack Development Mailing List (not for usage questions)<br>> >> Unsubscribe:<br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> >><br>> >> __________________________________________________________________________<br>> >> OpenStack Development Mailing List (not for usage questions)<br>> >> Unsubscribe:<br>> >> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> >><br>> ><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>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/1d7d2452/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 42<br>> Date: Tue, 9 Jun 2015 20:21:16 +0000<br>> From: "Sousou, Imad" <imad.sousou@intel.com><br>> To: "openstack-dev@lists.openstack.org"<br>>  <openstack-dev@lists.openstack.org><br>> Subject: [openstack-dev] Request to post to this list EOM<br>> Message-ID:<br>>  <C4BBB0078BEEB64C9D37C8676219F87731F1A04E@FMSMSX108.amr.corp.intel.com><br>>  <br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/83ced002/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 43<br>> Date: Tue, 9 Jun 2015 20:28:07 +0000<br>> From: "Sousou, Imad" <imad.sousou@intel.com><br>> To: "openstack-dev@lists.openstack.org"<br>>  <openstack-dev@lists.openstack.org>,<br>>  "community-owner@lists.openstack.org"<br>>  <community-owner@lists.openstack.org>, "openstack@lists.openstack.org"<br>>  <openstack@lists.openstack.org><br>> Subject: [openstack-dev] OpenStack Diversity Working Group<br>> Message-ID:<br>>  <C4BBB0078BEEB64C9D37C8676219F87731F1A1F0@FMSMSX108.amr.corp.intel.com><br>>  <br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Stackers - We're happy to announce the creation of a Diversity Working Group. The genesis for this work group was a discussion at the May meeting of the OpenStack Board of Directors ahead of the Vancouver Summit.<br>> <br>> The Board is committed to fostering an inclusive and welcoming place for all people to collaborate to drive innovation and design cutting-edge data center capabilities, while finding the best answers to our most pressing challenges. To achieve this, the Board formed this Work Group to determine what actions are required to fulfill this commitment. Three Board members volunteered to work with community members in this Work Group and bring updates/requests to the Board for discussion and action on a regular basis, starting with the July meeting.<br>> <br>> If you're interested in joining this effort, please:<br>> <br>> *         Join the Foundation mail list to participate in discussions and shape the direction: click here<http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation><br>> <br>> *         Visit the wiki page for this work group to learn more about the charter: click here<https://wiki.openstack.org/wiki/Diversity><br>> <br>> *         Plan to join the kick-off IRC meeting and let us know what day/times work for you by accessing the Doodle here: click here<http://doodle.com/z85c23dtexx8qzq7><br>> <br>> We will send out the results of the Doodle to the mail list and look forward to working with you to foster a strong and diverse community.<br>> <br>> Thanks<br>> Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/2aa0fa23/attachment.html><br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> OpenStack-dev mailing list<br>> OpenStack-dev@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> <br>> <br>> End of OpenStack-dev Digest, Vol 38, Issue 37<br>> *********************************************<br>                                        </div></body>
</html>