[openstack-dev] OpenStack-dev Digest, Vol 51, Issue 6

Luck Dog dfhuangg at gmail.com
Tue Jul 5 02:51:50 UTC 2016


Hello everyone,
       I am running the devstack with patch Tricircle,according to steps
given by official net page,
https://github.com/openstack/tricircle#play-with-devstack.But it  always
failed at the same place.The errors are  listed  as follows.(according to
the stack.sh.logs)

Request body: {u'network': {u'router:external': True,
u'provider:network_type': u'flat', u'name': u'public',
u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m
^[[00;33mfrom (pid=29980) prepare_request_body
/opt/stack/neutron/neutron/api/v2/base.py:674^[[00m
2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver
[^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources
subnetpool have unlimited quota limit. It is not required to calculate
headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation
/opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m
2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver
[^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to
reserve 1 items for resource network. Total usage: 0; quota limit: 10;
headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation
/opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m
2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource
[^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate
failed^[[00m
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00mTraceback (most recent call last):
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/resource.py", line
78, in resource
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    result = method(request=request, **args)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
424, in create
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    return self._create(request, body, **kwargs)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in
wrapper
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    ectxt.value = e.inner_exc
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221,
in __exit__
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    self.force_reraise()
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197,
in force_reraise
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    six.reraise(self.type_, self.value, self.tb)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in
wrapper
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    return f(*args, **kwargs)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
535, in _create
[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    return obj_creator(request.context, **kwargs)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File "/opt/stack/tricircle/tricircle/network/plugin.py",
line 238, in create_network
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    is_external =
self._ensure_az_set_for_external_network(net_data)
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m  File "/opt/stack/tricircle/tricircle/network/plugin.py",
line 184, in _ensure_az_set_for_external_network
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m    raise t_exceptions.ExternalNetPodNotSpecify()
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00mExternalNetPodNotSpecify: Pod for external network not
specified
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m
2016-06-29 17:56:04.439 ^[[00;36mINFO neutron.wsgi
[^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
13869ba8005b480bbcbe17b2695fd5e2^[[00;36m] ^[[01;35m^[[00;36m127.0.0.1 - -
[29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368
0.147805^[[00m

Part of the final printed errors on terminal are:

Request Failed: internal server error while processing your request.
Neutron server returns request_ids:
['req-e97f6276-8e19-408b-829a-004a31256453']
lib/neutron_plugins/services/l3:create_neutron_initial_network:203
lib/neutron_plugins/services/l3:create_neutron_initial_network:207
[ERROR] /home/sword/DevStack/functions-common:207 Failure creating
EXT_NET_ID for public

I run it several times but still failed. I was in China  main  land but I
bought a VPN. So it may not be due to the
network. @Fawaz Mohammed,Also, I conducted your suggestions and failed at
last.

I wish someone could help me  with this question.thanks!

Best,
Dongfeng

2016-07-04 17:36 GMT+08:00 <openstack-dev-request at lists.openstack.org>:

> Send OpenStack-dev mailing list submissions to
>         openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
>         openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: [Nova] Questions about instance actions' update and
>       finish (Matt Riedemann)
>    2. Re: [manila][stable] liberty periodic bitrot jobs have been
>       failing more than a week (Matt Riedemann)
>    3. Re: Syntribos Error : AttributeError: 'tuple' object has no
>       attribute 'headers' (David Stanek)
>    4. Re: [tricircle] Error when running Devstack (Fawaz Mohammed)
>    5. Re: Openstack Mitaka Neutron LBaaS Question (Fawaz Mohammed)
>    6. [nova] Fail build request if we can't inject files?
>       (Matt Riedemann)
>    7. Re: Syntribos Error : AttributeError: 'tuple'     object has no
>       attribute 'headers' (OpenStack Mailing List Archive)
>    8. Re: [manila][stable] liberty periodic bitrot jobs have been
>       failing more than a week (Valeriy Ponomaryov)
>    9. Re: New Python35 Jobs coming (Henry Gessau)
>   10. [kolla][horizon] Out of branch horizon plugins? (Dave Walker)
>   11. Re: New Python35 Jobs coming (Clint Byrum)
>   12. [Kolla] [docker] Storage-driver and loopback usage? (Gerard Braad)
>   13. Re: [grenade] upgrades vs rootwrap (Angus Lees)
>   14. [keystone] spec freeze on july 8th, 2016 (Steve Martinelli)
>   15. Re: [Kolla] [docker] Storage-driver and loopback  usage?
>       (Jeffrey Zhang)
>   16. Re: [stable][all] Tagging kilo-eol for "the world"
>       (Joshua Hesketh)
>   17. Re: New Python35 Jobs coming (Andreas Jaeger)
>   18. Re: New Python35 Jobs coming (Denis Makogon)
>   19. Re: [Nova] Questions about instance actions' update and
>       finish (Zhenyu Zheng)
>   20. Re: [mistral][osc-lib][openstackclient] is it too early for
>       orc-lib? (Renat Akhmerov)
>   21. Re: [nova][infra][ci] bulk repeating a test job on a single
>       review in parallel ? (Kashyap Chamarthy)
>   22. [tricircle] (Luck Dog)
>   23. Re: New Python35 Jobs coming (Victor Stinner)
>   24. Re: Openstack Mitaka Neutron LBaaS Question (Elena Ezhova)
>   25. Re: [kuryr] kuryr-libnetwork split (Antoni Segura Puimedon)
>   26. Re: [neutron][upgrades] Bi-weekly upgrades work status.
>       6/20/2016 (Damon Wang)
>   27. Re: [kolla][ironic] My thoughts on Kolla + BiFrost
>       integration (Stephen Hindle)
>   28. Re: [daisycloud-core] [kolla] Kolla Mitaka
>       requirementssupported by CentOS (hu.zhijiang at zte.com.cn)
>   29. Re: [daisycloud-core] [kolla] Kolla Mitaka
>       requirementssupported by CentOS (Gerard Braad)
>   30. ??: [probably forge email???????]Re:  [daisycloud-core] Kolla
>       Mitaka requirementssupported by CentOS (hu.zhijiang at zte.com.cn)
>   31. Re: [Openstack-operators] [nova] Fail build request if we
>       can't inject files? (Daniel P. Berrange)
>   32. Re: [all][Python 3.4-3.5] Async python clients (Julien Danjou)
>   33. Re: [Fuel] - Nominate Maksim Malchuk to Fuel      Library Core
>       (Sergii Golovatiuk)
>   34. Re: [all][Python 3.4-3.5] Async python clients (Denis Makogon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 3 Jul 2016 08:05:06 -0500
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Questions about instance actions'
>         update and finish
> Message-ID: <d53105c4-4184-a737-a27c-f8b981cabb8b at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 7/3/2016 6:21 AM, Alex Xu wrote:
> >
> >
> > 2016-07-02 2:32 GMT+08:00 Sean Dague <sean at dague.net
> > <mailto:sean at dague.net>>:
> >
> >     On 06/30/2016 08:31 AM, Andrew Laski wrote:
> >     >
> >     >
> >     > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:
> >     >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:
> >     >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:
> >     >>>>
> >     >>>>
> >     >>>>
> >     >>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
> >     >>>>> How about I sync updated_at and created_at in my patch, and
> leave the
> >     >>>>> finish to the other BP, by this way, I can use updated_at for
> the
> >     >>>>> timestamp filter I added and it don't need to change again
> once the
> >     >>>>> finish BP is complete.
> >     >>>>
> >     >>>> Sounds good to me.
> >     >>>>
> >     >>>
> >     >>> It's been a long day so my memory might be fried, but the
> options we
> >     >>> talked about in the API meeting were:
> >     >>>
> >     >>> 1. Setting updated_at = created_at when the instance action
> record is
> >     >>> created. Laski likes this, I'm not crazy about it, especially
> since we
> >     >>> don't do that for anything else.
> >     >
> >     > I would actually like for us to do this generally. I have the same
> >     > thinking as Ed does elsewhere in this thread, the creation of a
> record
> >     > is an update of that record. So take my comments as applying to
> Nova
> >     > overall and not just this issue.
> >
> >     Agree. Also it just simplifies a number of things. We should just
> start
> >     doing this going forward, and probably put some online data
> migrations
> >     in place next cycle to update all the old records. Once updated_at
> can't
> >     be null, we can handle things like this a bit better.
> >
> >
> > The marker should be a column with UniqueConstraint, the updated_at is
> > not. But if we say the accuracy is ok, there will have problem with
> > updated_at as None.
>
> Yeah I thought about this later, we don't use a timestamp field as a
> marker for anything else, and as noted it's not a non-nullable unique
> field, plus it's mutable which worries me for a marker field (created_at
> wouldn't change, but updated_at could).
>
> >
> > Anyway, we already freeze... probably we can begin to fix the updated_at
> > problem first.
> >
> >
> >     >>> 2. Update the instance action's updated_at when instance action
> events
> >     >>> are created. I like this since the instance action is like a
> parent
> >     >>> resource and the event is the child, so when we create/modify an
> event
> >     >>> we can consider it an update to the parent. Laski thought this
> might be
> >     >>> weird UX given we don't expose instance action events in the
> REST API
> >     >>> unless you're an admin. This is also probably not something we'd
> do for
> >     >>> other related resources like server groups and server group
> members (but
> >     >>> we don't page on those either right now).
> >     >
> >     > Right. My concern is just that the ordering of actions can change
> based
> >     > on events happening which are not visible to the user. However
> thinking
> >     > about it further we don't really allow multiple actions at once,
> except
> >     > for a few special cases like delete, so this may not end up
> affecting
> >     > any ordering as actions are mostly serial. I think this is a fine
> >     > solution for the issue at hand. I just think #1 is a more general
> >     > solution.
> >     >
> >     >>>
> >     >>> 3. Order the results by updated_at,created_at so that if
> updated_at
> >     >>> isn't set for older records, created_at will be used. I think we
> all
> >     >>> agreed in the meeting to do this regardless of #1 or #2 above.
> >
> >     I kind of hate that as the order, because then the marker is going to
> >     have to be really funny double timestamp, right?
> >
> >
> > The marker only needs to fill with the unique value. There isn't any
> > problem order with multiple column. Some time we need order with
> > mulitple column for stable order when the first order column is
> > without UniqueConstraint.
> >
> >
> >
> >     I guess that's the one thing I don't see in this patch is a
> functional
> >     test that actually loads up instance actions and iterates through
> >     demonstrating the pagination.
> >
> >             -Sean
> >
> >     --
> >     Sean Dague
> >     http://dague.net
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 Jul 2016 08:19:55 -0500
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [manila][stable] liberty periodic bitrot
>         jobs have been failing more than a week
> Message-ID: <37858941-062c-8fd7-9794-9f4d9588a446 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 7/1/2016 8:18 PM, Ravi, Goutham wrote:
> > Thanks Matt.
> >
> > https://review.openstack.org/#/c/334220 adds the upper constraints.
> >
> > --
> > Goutham
> >
> >
> > On 7/1/16, 5:08 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
> >
> > The manila periodic stable/liberty jobs have been failing for at least a
> > week.
> >
> > It looks like manila isn't using upper-constraints when running unit
> > tests, not even on stable/mitaka or master. So in liberty it's pulling
> > in uncapped oslo.utils even though the upper constraint for oslo.utils
> > in liberty is 3.2.
> >
> > Who from the manila team is going to be working on fixing this, either
> > via getting upper-constraints in place in the tox.ini for manila (on all
> > supported branches) or performing some kind of workaround in the code?
> >
>
> Thanks.
>
> I noticed that there is no Tempest / devstack job run against the
> stable/liberty change - why is there no integration testing of Manila in
> stable/liberty outside of 3rd party CI (which is not voting)?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 3 Jul 2016 09:23:07 -0400
> From: David Stanek <dstanek at dstanek.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'
>         object has no attribute 'headers'
> Message-ID: <20160703132307.GA45453 at mba>
> Content-Type: text/plain; charset=us-ascii
>
> On 07/02 at 15:52, OpenStack Mailing List Archive wrote:
> > Link: https://openstack.nimeyo.com/89478/?show=89478#q89478
> > From: run2obtain <run2obtain at gmail.com>
> >
> >
> > Hi... I tried to use OpenStack Syntribos today for security testing
> against my
> > devstack kilo cloud. I followed installation and configuration
> instructions
> > provided at the openstack syntribos repo .Unfortunately, I received some
> errors
> > after running the command : syntribos keystone.config
> .opencafe/templates/
> > keystone/roles_get.txt . The errors are File "/usr/local/lib/python2.7/
> > dist-packages/syntribos/extensions/identity/client.py", line 146, in
> > get_token_v3 return r.headers["X-Subject-Token"] AttributeError: 'tuple'
> object
> > has no attribute 'headers'. ' I have not been successful at discovering
> what
> > could be wrong or how to resolve this issue, even after googling. Does
> anyone
> > have a hint as to how to resolve this issue. Many thanks for your
> anticipated
> > response.
> >
>
> A quick look at the code[1] show that the HTTP client used by the identity
> client actually returns a tuple instead of a response object. The tuple
> contains two items: a response object and a signal handler object.
>
> This is the first I've heard of this project, so I was very disappointed
> to not find any docs for it.
>
> 1.
> https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143
>
> --
> David Stanek
> web: http://dstanek.com
> blog: http://traceback.org
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Jul 2016 17:59:25 +0400
> From: Fawaz Mohammed <fawaz.moh.ibraheem at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tricircle] Error when running Devstack
> Message-ID:
>         <
> CA+NahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5+LEsyTMvNsh3g-A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Dongfeng,
>
> I've noted in the title [Tricircle], but in your body mail, nothing related
> to Tricircle!
>
> It's not recommended to use the sample configuration file as it's, make
> sure that you edit it as per your preferred configuration.
>
> Also, note that it's good to run stack.sh as stack user, you can create
> stack user by running:
> $sudo /devstack/tools/create-stack-user.sh
> Then, move the devstack folder to stack home user, or clone it again:
> stack at Host$cd ~
> stack at host$git clone https://git.openstack.org/openstack-dev/devstack
> Edit your local.conf configuration file, then run stack.sh script.
>
>
>
> On Sun, Jul 3, 2016 at 3:41 PM, Luck Dog <dfhuangg at gmail.com> wrote:
>
> > Hello everyone,
> >
> > I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An
> > error turns up  before it successfully starts. My steps are:
> > 1), Git clone DevStack,
> > 2), Copy devstack/local.conf.sample to DevStack folder and rename it to
> > local.conf.
> > The  errors are as follows?
> > Request Failed: internal server error while processing your request.
> > Neutron server returns request_ids:
> > ['req-e97f6276-8e19-408b-829a-004a31256453']
> > lib/neutron_plugins/services/l3:create_neutron_initial_network:203
> > lib/neutron_plugins/services/l3:create_neutron_initial_network:207
> > [ERROR] /home/sword/DevStack/functions-common:207 Failure creating
> > EXT_NET_ID for public
> >
> > I don't know whether it is  my wrong configuration of computer or the
> > server error, I wish someone can help me with the problem. thanks!
> >
> > Best regards,
> > Dongfeng
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/8584112c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Sun, 3 Jul 2016 18:10:02 +0400
> From: Fawaz Mohammed <fawaz.moh.ibraheem at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question
> Message-ID:
>         <CA+NahOUMgiNoKAnzrZKrOgo=Eigrpv8VHaSZzPxwC=
> WLtQCnEQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Wally,
>
> Make sure that neutron-server is running. Check neutron-server, and
> neutron-l3-agent logs.
>
> ---
> Regards,
> Fawaz Mohammed
>  .
>
>
>
> On Sat, Jul 2, 2016 at 2:24 AM, zhihao wang <wangzhihaocom at hotmail.com>
> wrote:
>
> > Dear OpenStack Dev member:
> >
> > May I ask you some question about neutron lbaaS?
> >
> > How to install the neutron LBaaS with Octavia in Mitaka?
> > I followed these two guide ,but which one I should use? (My openstack is
> > Mitaka , 1 controller, 2 compute nodes)
> >
> > https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun  --  Ubuntu
> > Packages Setup
> > http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
> > -- Configuring LBaaS v2 with Octavia
> >
> > Here is what I did:
> >
> > pip install octavia
> >
> > and then :
> > vim /etc/neutron/neutron.conf
> > service_plugins =
> > router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
> >
> > [service_providers]
> > service_provider =
> >
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
> >
> > /etc/openstack-dashboard/local_settings.py
> >
> >
> > OPENSTACK_NEUTRON_NETWORK = {
> >     'enable_lb': True
> > }
> >
> >
> > And then I restart all the neutron service and apache server
> >   service neutron-server restart
> >   service neutron-dhcp-agent restart
> >   service neutron-metadata-agent restart
> >   service neutron-l3-agent restart
> >
> > but and then i ran the command neutron agent-list, it return this. I am
> > wondering what is wrong with this? how can I install Neutron LaaS?
> >
> > root at controller:~# neutron agent-list
> > Unable to establish connection to
> http://controller:9696/v2.0/agents.json
> >
> >
> > Please help
> >
> > Thanks so much
> >
> > Thanks
> > Wally
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/c3bd39ba/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Sun, 3 Jul 2016 10:08:04 -0500
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>,
>         "openstack-operators at lists.openstack.org"
>         <openstack-operators at lists.openstack.org>
> Subject: [openstack-dev] [nova] Fail build request if we can't inject
>         files?
> Message-ID: <3e959d6e-09b3-4047-ff31-c44efab981f3 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it
> runs ssh validation + neutron + config drive + metadata service, which
> will test the virtual device tagging 2.32 microversion API (added last
> week).
>
> The job has a file injection test that fails consistently which is
> keeping it from being voting.
>
> After debugging, the problem is the files to inject are silently ignored
> because n-cpu is configured with libvirt.inject_partition=-2 by default.
> That disables file injection:
>
>
> https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030
>
> We don't even log a warning if the user requested files to inject and we
> can't honor it. If I were a user and tried to inject files when creating
> a server but they didn't show up in the guest, I'd open a support ticket
> against my cloud provider. So I don't think a warning (that only the
> admin sees) is sufficient here. This isn't something that's discoverable
> from the API either, it's really host configuration / capability
> (something we still need to tackle).
>
> So I propose that we fail the server create request in this case since
> the user asked nova to inject files but n-cpu is configured to not allow
> that.
>
> I'd also think that this should trigger a reschedule to another compute.
> However, if all computes have disabled file injection, which is the
> default:
>
>
> https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66
>
> Then they'll retry 3 times and fail with an instance in error state. So
> I'm not sure if rescheduling in this case is useful. I'd think that
> deployments are either allowing file injection globally (if using
> libvirt) of they aren't, but would need some operators to chime in here.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 3 Jul 2016 09:09:20 -0700
> From: OpenStack Mailing List Archive <corpqa at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'
>         object has no attribute 'headers'
> Message-ID: <1d1282b2e4d7eb4d4c701c0ed0b55551 at openstack.nimeyo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/3013a3a5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Sun, 3 Jul 2016 19:54:19 +0300
> From: Valeriy Ponomaryov <vponomaryov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [manila][stable] liberty periodic bitrot
>         jobs have been failing more than a week
> Message-ID:
>         <CAPnpNOVTxe6PcuLbZ_3uu-fGZeReVw0G=
> pko8KTP3AKWQx-8sQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Matt, it is not related to branch. Tempest jobs do run only when specific
> files are changed. See [1].
>
> [1]
>
> https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066
>
> On Sun, Jul 3, 2016 at 4:19 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com
> >
> wrote:
>
> > On 7/1/2016 8:18 PM, Ravi, Goutham wrote:
> >
> >> Thanks Matt.
> >>
> >> https://review.openstack.org/#/c/334220 adds the upper constraints.
> >>
> >> --
> >> Goutham
> >>
> >>
> >> On 7/1/16, 5:08 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com>
> wrote:
> >>
> >> The manila periodic stable/liberty jobs have been failing for at least a
> >> week.
> >>
> >> It looks like manila isn't using upper-constraints when running unit
> >> tests, not even on stable/mitaka or master. So in liberty it's pulling
> >> in uncapped oslo.utils even though the upper constraint for oslo.utils
> >> in liberty is 3.2.
> >>
> >> Who from the manila team is going to be working on fixing this, either
> >> via getting upper-constraints in place in the tox.ini for manila (on all
> >> supported branches) or performing some kind of workaround in the code?
> >>
> >>
> > Thanks.
> >
> > I noticed that there is no Tempest / devstack job run against the
> > stable/liberty change - why is there no integration testing of Manila in
> > stable/liberty outside of 3rd party CI (which is not voting)?
> >
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomaryov at mirantis.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/b9601a80/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Sun, 3 Jul 2016 15:26:23 -0400
> From: Henry Gessau <HenryG at gessau.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] New Python35 Jobs coming
> Message-ID: <314a3c1e-7111-38ab-3545-d3cb302a4d02 at gessau.net>
> Content-Type: text/plain; charset=utf-8
>
> Clark Boylan <cboylan at sapwetik.org> wrote:
> > The infra team is working on taking advantage of the new Ubuntu Xenial
> > release including running unittests on python35. The current plan is to
> > get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> > 5, 2016). This will add non voting python35 tests restricted to >=
> > master/Newton on all projects that had python34 testing.
> >
> > The expectation is that in many cases python35 tests will just work if
> > python34 testing was also working. If this is the case for your project
> > you can propose a change to openstack-infra/project-config to make these
> > jobs voting against your project. You should only need to edit
> > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> > portion of the python35 jobs to do this.
> >
> > We do however expect that there will be a large group of failed tests
> > too. If your project has a specific tox.ini py34 target to restrict
> > python3 testing to a specific list of tests you will need to add a tox
> > target for py35 that does the same thing as the py34 target. We have
> > also seen bug reports against some projects whose tests rely on stable
> > error messages from Python itself which isn't always the case across
> > version changes so these tests will need to be updated as well.
> >
> > Note this change will not add python35 jobs for cases where projects
> > have special tox targets. This is restricted just to the default py35
> > unittesting.
> >
> > As always let us know if you questions,
> > Clark
>
> How soon can projects replace py34 with py35?
>
> I tried py35 for neutron locally, and it ran without errors.
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 3 Jul 2016 21:15:37 +0100
> From: Dave Walker <email at daviey.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [kolla][horizon] Out of branch horizon
>         plugins?
> Message-ID:
>         <
> CACyjiAhWiOTvZjAKyibSC4wpHyK6c9+cNK0dzy_dFxSgX+ckAA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Whilst writing a Kolla plugin, I noticed some issues with the way Horizon
> is configured in Kolla.
>
> Horizon is increasingly embracing a plugin architecture with UI's and
> Dashboards being maintained outside of Horizon's tree.
>
> These can be found with the type:horizon-plugin tag in openstack/governance
> [0], with 16 projects at current.
>
> This isn't really addressed in Kolla, and is a little awkward to integrate
> as the horizon docker image is pure horizon.
>
> Some projects have a tools/register_plugin.sh which performs the grunt
> work, where as others require a workflow similar to:
>
> cp /path/to/projects/new/panel openstack_dashboard/local/enabled/
> cp /path/to/local/defualt/settings
> openstack_dashboard/local/local_settings.d/
> cp /path/to/*policy.json openstack_dashboard/conf/
> # compress if environment wants it
> ./manage.py collectstatic
> ./manage.py compress
>
> (Separately, it would be nice if this was standardised.. but not the topic
> of this thread)
>
> It would seem logical to pack all of these into the horizon docker image,
> and add a symlink into dashboard/local/enabled via ansible, policy.json and
> default settings with some conditionals if enabled_$service... but this
> will make the horizon docker image larger and more complicated.
>
> What are your thoughts?
>
> [0]
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> --
> Kind Regards,
> Dave Walker
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/dd00980b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 11
> Date: Sun, 03 Jul 2016 17:20:42 -0700
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] New Python35 Jobs coming
> Message-ID: <1467591512-sup-6679 at fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Henry Gessau's message of 2016-07-03 15:26:23 -0400:
> > Clark Boylan <cboylan at sapwetik.org> wrote:
> > > The infra team is working on taking advantage of the new Ubuntu Xenial
> > > release including running unittests on python35. The current plan is to
> > > get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> > > 5, 2016). This will add non voting python35 tests restricted to >=
> > > master/Newton on all projects that had python34 testing.
> > >
> > > The expectation is that in many cases python35 tests will just work if
> > > python34 testing was also working. If this is the case for your project
> > > you can propose a change to openstack-infra/project-config to make
> these
> > > jobs voting against your project. You should only need to edit
> > > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> > > portion of the python35 jobs to do this.
> > >
> > > We do however expect that there will be a large group of failed tests
> > > too. If your project has a specific tox.ini py34 target to restrict
> > > python3 testing to a specific list of tests you will need to add a tox
> > > target for py35 that does the same thing as the py34 target. We have
> > > also seen bug reports against some projects whose tests rely on stable
> > > error messages from Python itself which isn't always the case across
> > > version changes so these tests will need to be updated as well.
> > >
> > > Note this change will not add python35 jobs for cases where projects
> > > have special tox targets. This is restricted just to the default py35
> > > unittesting.
> > >
> > > As always let us know if you questions,
> > > Clark
> >
> > How soon can projects replace py34 with py35?
> >
> > I tried py35 for neutron locally, and it ran without errors.
> >
>
> I think we should be aggressive on python 3.5 vs. 3.4, since anywhere
> that shipped 3.4 also shipped 2.7. Otherwise we end up wasting time on
> whatever subtle differences there are.
>
>
>
> ------------------------------
>
> Message: 12
> Date: Mon, 4 Jul 2016 11:00:50 +0800
> From: Gerard Braad <me at gbraad.nl>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Kolla] [docker] Storage-driver and loopback
>         usage?
> Message-ID:
>         <CAGrH30WswSoHyeSOSNse3kJcPwkZOdLxu=
> Fd9ki7UGGu3Xw_ww at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi guys,
>
>
> This weekend I have been looking into some issues I encountered with
> `ostree` inside a Docker container, and this seemed to have been
> caused by the use of loopback storage with device mapper. After this
> experience I was wondering what Kolla did...
>
> Usually for development purpose, or on a laptop, it is easy to just
> work out-of-the-box. But I would not consider using devicemapper after
> this experience as a pleasant experience. I moved to all development
> environment using OverlayFS, and will evaluate this for the time
> being...
>
> What do you guys think or use? And what about the quickstart? I was
> unable to find a statement about this. I did find a change of the
> storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what
> is used in CI?
>
> regards,
>
>
> Gerard
>
> --
>
>    Gerard Braad | http://gbraad.nl
>    [ Doing Open Source Matters ]
>
>
>
> ------------------------------
>
> Message: 13
> Date: Mon, 04 Jul 2016 03:25:06 +0000
> From: Angus Lees <gus at inodes.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [grenade] upgrades vs rootwrap
> Message-ID:
>         <
> CAPA_H3fkw+MB_AjHVAmS29+viS07PJXdM3RukK0fhx-gv2fyRw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sat, 2 Jul 2016 at 01:02 Matt Riedemann <mriedem at linux.vnet.ibm.com>
> wrote:
>
> > On 6/28/2016 4:56 PM, Sean Dague wrote:
> > > On 06/28/2016 01:46 AM, Angus Lees wrote:
> > >> Ok, thanks for the in-depth explanation.
> > >>
> > >> My take away is that we need to file any rootwrap updates as
> exceptions
> > >> for now (so releasenotes and grenade scripts).
> > >
> > > That is definitely the fall back if there is no better idea. However,
> we
> > > should try really hard to figure out if there is a non manual way
> > > through this. Even if that means some compat code that we keep for a
> > > release to just bridge the gap.
> > >
> > >     -Sean
> > >
> >
> > Walter had this for os-brick:
> >
> > https://review.openstack.org/#/c/329586/
> >
> > That would fallback to rootwrap if privsep doesn't work / not available.
> > That could be a workaround for upgrading with os-brick for Newton, with
> > a big fat warning logged if we use it, and then drop it in Ocata and
> > require privsep.
> >
>
> Yes, this is basically a version of "submit the rootwrap filter, then wait
> 6 months before submitting the code that needs it".   If we don't wish to
> use the exception mechanism (or adjust the policy to upgrade conf before
> code as I described earlier), then we can certainly do this.  Rather than
> log a big fat warning if we use privsep, we may as well just revert the
> privsep change for os-brick and then resubmit it next cycle.
>
> This thread topic isn't actually about privsep however, although a
> migration to privsep will mostly mitigate this in the future which is
> perhaps why it is causing topic collisions for everyone.
>
> I see there are already a few other additions to the rootwrap filters in
> nova/cinder (the comments suggest (nova) libvirt/imagebackend.py, (cinder)
> remotefs.py, and (both) vzstorage.py).  The various privsep-only
> suggestions about fallback strategies don't help in these other examples.
> Any
> corresponding code changes that rely on these new filters will also need to
> be reverted and resubmitted during next cycle - or do what usually happens
> and slip under the radar as they are not exercised by grenade.
>
>  - Gus
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b8832f07/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> Date: Sun, 3 Jul 2016 23:41:22 -0400
> From: Steve Martinelli <s.martinelli at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [keystone] spec freeze on july 8th, 2016
> Message-ID:
>         <CAHc_MXHV+bj-c36=bDxUZ1SU=
> FFy-jy2ssSnaVEHFxd3fLGFag at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The keystone spec freeze is on july 8th. I am in the process of going
> through the open specs [1]
>
> I will be commenting if I think it is a potential candidate for the Newton
> based on how far along the spec is, its complexity, core reviewer attention
> and priority. (Thanks Matt R for the wording)
>
> I'd like spend the bulk of the next keystone meeting on Tuesday discussing
> the open specs. If you are authoring one, please try to attend.
>
> [1]
>
> https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/046649b3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 15
> Date: Mon, 4 Jul 2016 11:58:40 +0800
> From: Jeffrey Zhang <zhang.lei.fly at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Kolla] [docker] Storage-driver and
>         loopback        usage?
> Message-ID:
>         <CAATxhGftHC_oJMkX-vabJugNCK+DBom6m3qGZj_051tZS=
> 7fHg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Gerard,
>
> Here is what the docker official recommend[0]. In the prod env, the they
> recommend
> using the direct-lvm driver.
>
> Kolla has no recommendation now. In the dev process, i know someone use
> overlayfs,
> some use btrfs. These two are both faster than others.
>
>
> [0] https://docs.docker.com/engine/userguide/storagedriver/selectadriver/
>
> On Mon, Jul 4, 2016 at 11:00 AM, Gerard Braad <me at gbraad.nl> wrote:
>
> > Hi guys,
> >
> >
> > This weekend I have been looking into some issues I encountered with
> > `ostree` inside a Docker container, and this seemed to have been
> > caused by the use of loopback storage with device mapper. After this
> > experience I was wondering what Kolla did...
> >
> > Usually for development purpose, or on a laptop, it is easy to just
> > work out-of-the-box. But I would not consider using devicemapper after
> > this experience as a pleasant experience. I moved to all development
> > environment using OverlayFS, and will evaluate this for the time
> > being...
> >
> > What do you guys think or use? And what about the quickstart? I was
> > unable to find a statement about this. I did find a change of the
> > storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what
> > is used in CI?
> >
> > regards,
> >
> >
> > Gerard
> >
> > --
> >
> >    Gerard Braad | http://gbraad.nl
> >    [ Doing Open Source Matters ]
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/cf4c7da8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 16
> Date: Mon, 4 Jul 2016 14:33:08 +1000
> From: Joshua Hesketh <joshua.hesketh at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the
>         world"
> Message-ID:
>         <
> CA+DTi5w-azo949HhOnp7gufu0Lsov77C1dUnHaBG_8SVneGD+g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Jul 1, 2016 at 9:26 PM, Jesse Pretorius <
> Jesse.Pretorius at rackspace.co.uk> wrote:
>
> > Hi all,
> >
> > Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented
> > we?ve requested a final tag [1]. Once that merges we are ready to have
> our
> > kilo-eol tag implemented and the ?kilo? branch removed.
> >
>
> I assume you want to wait for the tag to merge before removing the branch?
>
>
> >
> > Just to make life interesting, we still have leftover ?juno? and
> > ?icehouse? branches and would like to implement eol tags for them too. I
> > think we have the appropriate skips in place for the juno branch so there
> > should be no funky post-tag jobs kicking off for them, but the icehouse
> > branch may end up with some unknown jobs kicking off. If you can help
> > identify the changes we need to get implemented into project-config then
> we
> > can be rid of the old cruft.
> >
>
> The only tag job I can see for openstack-ansible* projects is the
> releasenotes one. This should be harmless as it just generates the notes
> for mitaka and liberty branches. I'm going to hold off until the final tag
> has merged anyway if you want to confirm this first.
>
> Cheers,
> Josh
>
>
>
> > Thanks,
> >
> > Jesse
> >
> > ------------------------------
> > Rackspace Limited is a company registered in England & Wales (company
> > registered number 03897010) whose registered office is at 5 Millington
> > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
> policy
> > can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> > message may contain confidential or privileged information intended for
> the
> > recipient. Any dissemination, distribution or copying of the enclosed
> > material is prohibited. If you receive this transmission in error, please
> > notify us immediately by e-mail at abuse at rackspace.com and delete the
> > original message. Your cooperation is appreciated.
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/dfba39e6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 17
> Date: Mon, 4 Jul 2016 07:18:41 +0200
> From: Andreas Jaeger <aj at suse.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] New Python35 Jobs coming
> Message-ID: <5779F1B1.3080500 at suse.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On 07/03/2016 09:26 PM, Henry Gessau wrote:
> > Clark Boylan <cboylan at sapwetik.org> wrote:
> >> The infra team is working on taking advantage of the new Ubuntu Xenial
> >> release including running unittests on python35. The current plan is to
> >> get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> >> 5, 2016). This will add non voting python35 tests restricted to >=
> >> master/Newton on all projects that had python34 testing.
> >>
> >> The expectation is that in many cases python35 tests will just work if
> >> python34 testing was also working. If this is the case for your project
> >> you can propose a change to openstack-infra/project-config to make these
> >> jobs voting against your project. You should only need to edit
> >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> >> portion of the python35 jobs to do this.
> >>
> >> We do however expect that there will be a large group of failed tests
> >> too. If your project has a specific tox.ini py34 target to restrict
> >> python3 testing to a specific list of tests you will need to add a tox
> >> target for py35 that does the same thing as the py34 target. We have
> >> also seen bug reports against some projects whose tests rely on stable
> >> error messages from Python itself which isn't always the case across
> >> version changes so these tests will need to be updated as well.
> >>
> >> Note this change will not add python35 jobs for cases where projects
> >> have special tox targets. This is restricted just to the default py35
> >> unittesting.
> >>
> >> As always let us know if you questions,
> >> Clark
> >
> > How soon can projects replace py34 with py35?
>
> As soon as you think your project is ready, you can replace py34 with
> py35 for master.
>
> >
> > I tried py35 for neutron locally, and it ran without errors.
>
> Then let it run for a day or two in our CI, discuss with neutron team,
> and send a patch for project-config to change the setup,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
>    GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
>        HRB 21284 (AG N?rnberg)
>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
>
> ------------------------------
>
> Message: 18
> Date: Mon, 4 Jul 2016 08:59:50 +0300
> From: Denis Makogon <lildee1991 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] New Python35 Jobs coming
> Message-ID:
>         <CALzSdtnL==UYr7-WS54G=
> HJrFxSHwESdF-W-W6Sz8F7jKe1wfQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-07-04 8:18 GMT+03:00 Andreas Jaeger <aj at suse.com>:
>
> > On 07/03/2016 09:26 PM, Henry Gessau wrote:
> > > Clark Boylan <cboylan at sapwetik.org> wrote:
> > >> The infra team is working on taking advantage of the new Ubuntu Xenial
> > >> release including running unittests on python35. The current plan is
> to
> > >> get https://review.openstack.org/#/c/336272/ merged next Tuesday
> (July
> > >> 5, 2016). This will add non voting python35 tests restricted to >=
> > >> master/Newton on all projects that had python34 testing.
> > >>
> > >> The expectation is that in many cases python35 tests will just work if
> > >> python34 testing was also working. If this is the case for your
> project
> > >> you can propose a change to openstack-infra/project-config to make
> these
> > >> jobs voting against your project. You should only need to edit
> > >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> > >> portion of the python35 jobs to do this.
> > >>
> > >> We do however expect that there will be a large group of failed tests
> > >> too. If your project has a specific tox.ini py34 target to restrict
> > >> python3 testing to a specific list of tests you will need to add a tox
> > >> target for py35 that does the same thing as the py34 target. We have
> > >> also seen bug reports against some projects whose tests rely on stable
> > >> error messages from Python itself which isn't always the case across
> > >> version changes so these tests will need to be updated as well.
> > >>
> > >> Note this change will not add python35 jobs for cases where projects
> > >> have special tox targets. This is restricted just to the default py35
> > >> unittesting.
> > >>
> > >> As always let us know if you questions,
> > >> Clark
> > >
> > > How soon can projects replace py34 with py35?
> >
> > As soon as you think your project is ready, you can replace py34 with
> > py35 for master.
> >
> > >
> > > I tried py35 for neutron locally, and it ran without errors.
> >
> > Then let it run for a day or two in our CI, discuss with neutron team,
> > and send a patch for project-config to change the setup,
> >
> >
> Can confirm that nova, glance, cinder, heat clients are py35 compatible.
>
>
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> >    GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
> >        HRB 21284 (AG N?rnberg)
> >     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8da19224/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 19
> Date: Mon, 4 Jul 2016 14:12:01 +0800
> From: Zhenyu Zheng <zhengzhenyulixi at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] Questions about instance actions'
>         update and finish
> Message-ID:
>         <CAO0b__-CoU9UDaVQEFrtL9=
> L92TbZhJUwkYfs9iA7R-xVM+pwg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'm willing to work on this, should this be a Blueprint for O?
>
> On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com
> >
> wrote:
>
> > On 7/3/2016 6:21 AM, Alex Xu wrote:
> >
> >>
> >>
> >> 2016-07-02 2:32 GMT+08:00 Sean Dague <sean at dague.net
> >> <mailto:sean at dague.net>>:
> >>
> >>
> >>     On 06/30/2016 08:31 AM, Andrew Laski wrote:
> >>     >
> >>     >
> >>     > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:
> >>     >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:
> >>     >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:
> >>     >>>>
> >>     >>>>
> >>     >>>>
> >>     >>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
> >>     >>>>> How about I sync updated_at and created_at in my patch, and
> >> leave the
> >>     >>>>> finish to the other BP, by this way, I can use updated_at for
> >> the
> >>     >>>>> timestamp filter I added and it don't need to change again
> once
> >> the
> >>     >>>>> finish BP is complete.
> >>     >>>>
> >>     >>>> Sounds good to me.
> >>     >>>>
> >>     >>>
> >>     >>> It's been a long day so my memory might be fried, but the
> options
> >> we
> >>     >>> talked about in the API meeting were:
> >>     >>>
> >>     >>> 1. Setting updated_at = created_at when the instance action
> >> record is
> >>     >>> created. Laski likes this, I'm not crazy about it, especially
> >> since we
> >>     >>> don't do that for anything else.
> >>     >
> >>     > I would actually like for us to do this generally. I have the same
> >>     > thinking as Ed does elsewhere in this thread, the creation of a
> >> record
> >>     > is an update of that record. So take my comments as applying to
> Nova
> >>     > overall and not just this issue.
> >>
> >>     Agree. Also it just simplifies a number of things. We should just
> >> start
> >>     doing this going forward, and probably put some online data
> migrations
> >>     in place next cycle to update all the old records. Once updated_at
> >> can't
> >>     be null, we can handle things like this a bit better.
> >>
> >>
> >> The marker should be a column with UniqueConstraint, the updated_at is
> >> not. But if we say the accuracy is ok, there will have problem with
> >> updated_at as None.
> >>
> >
> > Yeah I thought about this later, we don't use a timestamp field as a
> > marker for anything else, and as noted it's not a non-nullable unique
> > field, plus it's mutable which worries me for a marker field (created_at
> > wouldn't change, but updated_at could).
> >
> >
> >> Anyway, we already freeze... probably we can begin to fix the updated_at
> >> problem first.
> >>
> >>
> >>     >>> 2. Update the instance action's updated_at when instance action
> >> events
> >>     >>> are created. I like this since the instance action is like a
> >> parent
> >>     >>> resource and the event is the child, so when we create/modify an
> >> event
> >>     >>> we can consider it an update to the parent. Laski thought this
> >> might be
> >>     >>> weird UX given we don't expose instance action events in the
> REST
> >> API
> >>     >>> unless you're an admin. This is also probably not something we'd
> >> do for
> >>     >>> other related resources like server groups and server group
> >> members (but
> >>     >>> we don't page on those either right now).
> >>     >
> >>     > Right. My concern is just that the ordering of actions can change
> >> based
> >>     > on events happening which are not visible to the user. However
> >> thinking
> >>     > about it further we don't really allow multiple actions at once,
> >> except
> >>     > for a few special cases like delete, so this may not end up
> >> affecting
> >>     > any ordering as actions are mostly serial. I think this is a fine
> >>     > solution for the issue at hand. I just think #1 is a more general
> >>     > solution.
> >>     >
> >>     >>>
> >>     >>> 3. Order the results by updated_at,created_at so that if
> >> updated_at
> >>     >>> isn't set for older records, created_at will be used. I think we
> >> all
> >>     >>> agreed in the meeting to do this regardless of #1 or #2 above.
> >>
> >>     I kind of hate that as the order, because then the marker is going
> to
> >>     have to be really funny double timestamp, right?
> >>
> >>
> >> The marker only needs to fill with the unique value. There isn't any
> >> problem order with multiple column. Some time we need order with
> >> mulitple column for stable order when the first order column is
> >> without UniqueConstraint.
> >>
> >>
> >>
> >>     I guess that's the one thing I don't see in this patch is a
> functional
> >>     test that actually loads up instance actions and iterates through
> >>     demonstrating the pagination.
> >>
> >>             -Sean
> >>
> >>     --
> >>     Sean Dague
> >>     http://dague.net
> >>
> >>
> >>
> __________________________________________________________________________
> >>     OpenStack Development Mailing List (not for usage questions)
> >>     Unsubscribe:
> >>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >> >
> >>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 20
> Date: Mon, 4 Jul 2016 13:17:11 +0700
> From: Renat Akhmerov <renat.akhmerov at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it
>         too     early for orc-lib?
> Message-ID: <08997983-1194-4693-AD10-0DF81D014289 at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ok, based on what has been said here I suggest we keep this code for now.
> The changes were really minimal. If it creates some problems for us we can
> always easily revert.
>
> Renat Akhmerov
> @Nokia
>
> > On 01 Jul 2016, at 04:57, Steve Martinelli <s.martinelli at gmail.com>
> wrote:
> >
> > The crux of this, as Dean stated, is if the library wants OSC to always
> be pulled in (along with its many dependencies). We've seen folks include
> it in requirements, test-requirements, or even not at all (just document
> that OSC needs to be installed).
> >
> > I tossed up the idea with the ironic team of leveraging "extras" field
> to list OSC as optional, the change would look like:
> >
> > --- a/setup.cfg
> > +++ b/setup.cfg
> > @@ -22,6 +22,10 @@ classifier =
> >
> > +[extras]
> > +cli =
> > +  python-openstackclient>=3.0.0  # Apache-2.0
> > +
> >
> > So, if a user wanted to install just the python binding of ironicclient
> or mistralclient, they would do $ pip install python-ironicclient; if a
> user wanted the CLI as well.. $ pip install python-ironicclient[cli]
> >
> > Just an idea, it may be overkill and completely horrible.
> >
> > On Thu, Jun 30, 2016 at 5:29 PM, Dean Troyer <dtroyer at gmail.com <mailto:
> dtroyer at gmail.com>> wrote:
> > On Thu, Jun 30, 2016 at 8:38 AM, Hardik <
> hardik.parekh at nectechnologies.in <mailto:hardik.parekh at nectechnologies.in>>
> wrote:
> > Regarding osc-lib we have mainly two changes.
> >
> > 1) Used "utils" which is moved from openstackclient.common.utils to
> osc_lib.utils
> > 2) We used "command"  which wrapped in osc_lib from cliff.
> >
> > So I think there is no harm in keeping osc_lib.
> >
> > Admittedly the change to include osc-lib is a little early, I would have
> preferred until the other parts of it were a bit more stable.
> >
> > Also, I guess we do not need openstackclient to be installed  with
> mistralclient as if mistral is used in standalone mode
> > there is no need of openstackclient.
> >
> > The choice to include OSC as a dependency of a plugin/library rests
> entirely on the plugin team, and that will usually be determined by the
> answer to the question "Do you want all users of your library to have OSc
> installed even if they do not use it?"  or alternatively "Do you want to
> make your users remember to install OSC after installing the plugin?"
> >
> > Note that we do intend to have the capability on osc-lib to build an
> OSC-like stand-alone binary for plugins that would theoretically make
> installing OSC optional for stand-alone client users.  This is not complete
> yet, and as I said above, one reason I wish osc-lib had not been merged
> into plugin requirements yet.  That said, as long as you don't use those
> bits yet you will be fine, the utils, command, etc bits are stable, it is
> the clientmanager and shell parts that are still being developed.
> >
> > dt
> >
> > --
> >
> > Dean Troyer
> > dtroyer at gmail.com <mailto:dtroyer at gmail.com>
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <
> http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 21
> Date: Mon, 4 Jul 2016 08:22:11 +0200
> From: Kashyap Chamarthy <kchamart at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][infra][ci] bulk repeating a test
>         job on a single review in parallel ?
> Message-ID: <20160704062211.hunhz5zexs42lh43 at eukaryote>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Jul 01, 2016 at 02:35:34PM +0000, Jeremy Stanley wrote:
> > On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote:
> > > [Snip description of some nice debugging.]
> > >
> > > > I'd really love it if there was
> > > >
> > > >  1. the ability to request checking of just specific jobs eg
> > > >
> > > >       "recheck gate-tempest-dsvm-multinode-full"
> > >
> > > Yes, this would really be desirable.  I recall once asking this exact
> > > question on #openstack-infra, but can't find Infra team's response to
> > > that.
> >
> > The challenge here is that you want to make sure it can't be used to
> > recheck individual jobs until you have them all passing (like
> > picking a pin and tumbler lock). The temptation to recheck-spam
> > nondeterministically failing changes is already present, but this
> > would make it considerably easier still for people to introduce new
> > nondeterministic failures in projects. Maybe if it were tied to a
> > special pipeline type, and then we set it only for the experimental
> > pipeline or something?
>
> If it reduces nondeterministic spam for the CI Infra, and makes us
> achieve the task at hand, sure.  [/me need to educate himself a
> bit more on the Zuul pipeline infrastructure.]
>
> Worth filing this (and your 'idle pipeline' thought below) in the Zuul
> tracker here?
>
>     https://storyboard.openstack.org/#!/project/679
>
> > > >  2. the ability to request this recheck to run multiple
> > > >     times in parallel. eg if i just repeat the 'recheck'
> > > >     command many times on the same patchset # without
> > > >     waiting for results
> > >
> > > Yes, this too, would be _very_ useful for all the reasons you
> described.
> > [...]
> >
> > In the past we've discussed the option of having an "idle pipeline"
> > which repeatedly runs specified jobs only when there are unused
> > resources available, so that it doesn't significantly cut into our
> > resource pool when we're under high demand but still allows to
> > automatically collect a large amount of statistical data.
> >
> > Anyway, hopefully James Blair can weigh in on this, since Zuul is
> > basically in a feature freeze for a while to limit the number of
> > significant changes we'll need to forward-port into the v3 branch.
> > We'd want to discuss these new features in the context of Zuul v3
> > instead.
>
> > --
> > Jeremy Stanley
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> /kashyap
>
>
>
> ------------------------------
>
> Message: 22
> Date: Mon, 4 Jul 2016 15:10:47 +0800
> From: Luck Dog <dfhuangg at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [tricircle]
> Message-ID:
>         <
> CAL-y67hjWJ7XrOUjLiMZGV2va_5z_921jxMN3YL1a-GCh+i58w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everyone,
>
> I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An
> error turns up  before it successfully starts. Yesterday I clarified this
> question not  clearly enough?so I make a supplication for it. My steps are:
> 1), Git clone DevStack,
> 2), Copy devstack/local.conf.sample to DevStack folder and rename it to
> local.conf.
>
> the finished steps before the error turns up are listed as follows:
>
> 2016-06-29 09:11:53.081 | stack.sh log
> /opt/stack/logs/stack.sh.log.2016-06-29-171152
> 2016-06-29 09:12:19.797 | Installing package prerequisites
> 2016-06-29 09:15:27.224 | Installing OpenStack project source
> 2016-06-29 09:24:43.323 | Installing Tricircle
> 2016-06-29 09:24:55.979 | Starting RabbitMQ
> 2016-06-29 09:25:00.731 | Configuring and starting MySQL
> 2016-06-29 09:25:20.143 | Starting Keystone
> 2016-06-29 09:43:18.591 | Configuring Glance
> 2016-06-29 09:43:59.667 | Configuring Neutron
> 2016-06-29 09:46:30.646 | Configuring Cinder
> 2016-06-29 09:46:54.719 | Configuring Nova
> 2016-06-29 09:48:23.175 | Configuring Tricircle
> 2016-06-29 09:51:24.143 | Starting Glance
> 2016-06-29 09:52:11.133 | Uploading images
> 2016-06-29 09:52:45.460 | Starting Nova API
> 2016-06-29 09:53:27.511 | Starting Neutron
> 2016-06-29 09:54:21.476 | Creating initial neutron network elements
>
> The last errors when it stops running are:
>
> Request body: {u'network': {u'router:external': True,
> u'provider:network_type': u'flat', u'name': u'public',
> u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m
> ^[[00;33mfrom (pid=29980) prepare_request_body
> /opt/stack/neutron/neutron/api/v2/base.py:674^[[00m
> 2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources
> subnetpool have unlimited quota limit. It is not required to calculate
> headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation
> /opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m
> 2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to
> reserve 1 items for resource network. Total usage: 0; quota limit: 10;
> headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation
> /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m
> 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate
> failed^[[00m
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mTraceback (most recent call last):
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/resource.py", line
> 78, in resource
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    result = method(request=request, **args)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
> 424, in create
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    return self._create(request, body, **kwargs)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in
> wrapper
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    ectxt.value = e.inner_exc
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221,
> in __exit__
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    self.force_reraise()
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197,
> in force_reraise
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    six.reraise(self.type_, self.value, self.tb)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in
> wrapper
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    return f(*args, **kwargs)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
> 535, in _create
> [[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    return obj_creator(request.context, **kwargs)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/tricircle/tricircle/network/plugin.py",
> line 238, in create_network
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    is_external =
> self._ensure_az_set_for_external_network(net_data)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/tricircle/tricircle/network/plugin.py",
> line 184, in _ensure_az_set_for_external_network
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m    raise t_exceptions.ExternalNetPodNotSpecify()
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mExternalNetPodNotSpecify: Pod for external network not
> specified
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m
> 2016-06-29 17:56:04.439 ^[[00;36mINFO neutron.wsgi
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;36m] ^[[01;35m^[[00;36m127.0.0.1 - -
> [29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368
> 0.147805^[[00m
>
> the final printed errors on terminal are:
>
> Request Failed: internal server error while processing your request.
> Neutron server returns request_ids:
> ['req-e97f6276-8e19-408b-829a-004a31256453']
> lib/neutron_plugins/services/l3:create_neutron_initial_network:203
> lib/neutron_plugins/services/l3:create_neutron_initial_network:207
> [ERROR] /home/sword/DevStack/functions-common:207 Failure creating
> EXT_NET_ID for public
>
> I don't know whether it is  my wrong configuration of computer or the
> server error, I wish someone can help me with the problem. thanks!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a5c3d6b4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 23
> Date: Mon, 4 Jul 2016 09:14:00 +0200
> From: Victor Stinner <vstinner at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] New Python35 Jobs coming
> Message-ID: <dd699b65-c199-2ec5-4e4a-70236971d5d4 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Le 04/07/2016 ? 07:59, Denis Makogon a ?crit :
> >     Then let it run for a day or two in our CI, discuss with neutron
> team,
> >     and send a patch for project-config to change the setup,
> >
> > Can confirm that nova, glance, cinder, heat clients are py35 compatible.
>
> tox.ini of Nova, Swift and Trove need to be modified to copy/paste the
> whitelist of tests running on Python 3. Fix for Nova:
>
>     https://review.openstack.org/#/c/336432/
>
> Victor
>
>
>
> ------------------------------
>
> Message: 24
> Date: Mon, 4 Jul 2016 10:25:07 +0300
> From: Elena Ezhova <eezhova at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question
> Message-ID:
>         <CAFZxAhh=S0QfS+K=
> Jtgmx26TMH_goxYFEibKkBmVWLowL7FGUQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi!
>
> You also have to configure Octavia on your controller. The most
> straightforward way would be to follow the steps that are done in Octavia
> DevStack plugin
> <
> https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh
> >.
> There is also an overview presentation
> <
> https://docs.google.com/presentation/d/1AqmF3BnKLLu1W1n-XT5MSfVYrGue1JIwKSvjbWgGA6s/edit#slide=id.p4
> >
> which
> has some troubleshooting tips.
>
> Thanks,
> Elena
>
> On Sat, Jul 2, 2016 at 1:24 AM, zhihao wang <wangzhihaocom at hotmail.com>
> wrote:
>
> > Dear OpenStack Dev member:
> >
> > May I ask you some question about neutron lbaaS?
> >
> > How to install the neutron LBaaS with Octavia in Mitaka?
> > I followed these two guide ,but which one I should use? (My openstack is
> > Mitaka , 1 controller, 2 compute nodes)
> >
> > https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun  --  Ubuntu
> > Packages Setup
> > http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
> > -- Configuring LBaaS v2 with Octavia
> >
> > Here is what I did:
> >
> > pip install octavia
> >
> > and then :
> > vim /etc/neutron/neutron.conf
> > service_plugins =
> > router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
> >
> > [service_providers]
> > service_provider =
> >
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
> >
> > /etc/openstack-dashboard/local_settings.py
> >
> >
> > OPENSTACK_NEUTRON_NETWORK = {
> >     'enable_lb': True
> > }
> >
> >
> > And then I restart all the neutron service and apache server
> >   service neutron-server restart
> >   service neutron-dhcp-agent restart
> >   service neutron-metadata-agent restart
> >   service neutron-l3-agent restart
> >
> > but and then i ran the command neutron agent-list, it return this. I am
> > wondering what is wrong with this? how can I install Neutron LaaS?
> >
> > root at controller:~# neutron agent-list
> > Unable to establish connection to
> http://controller:9696/v2.0/agents.json
> >
> >
> > Please help
> >
> > Thanks so much
> >
> > Thanks
> > Wally
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/26f31912/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 25
> Date: Mon, 4 Jul 2016 09:38:19 +0200
> From: Antoni Segura Puimedon <toni+openstackml at midokura.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split
> Message-ID:
>         <CAP8JW8DxfO+KMPKriHST2w-3k_zRKi_yKu6j=8j2En=
> QqR3u4A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Jul 1, 2016 at 7:58 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
>
> > Excerpts from Jeremy Stanley's message of 2016-07-01 15:05:30 +0000:
> > > On 2016-07-01 08:26:13 -0500 (-0500), Monty Taylor wrote:
> > > [...]
> > > > Check with Doug Hellman about namespaces. We used to use them in some
> > > > oslo things and had to step away from them because of some pretty
> weird
> > > > and horrible breakage issues.
> > > [...]
> > >
> > > Or read the associated Oslo spec from when that was done:
> > >
> > > <URL:
> >
> https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html
> > >
> > >
> >
> > Yes, please don't use python namespaces. It's a cool feature, as you
> > say, but the setuptools implementation available for Python 2 has some
> > buggy edge cases that we hit on a regular basis before moving back to
> > regular packages. It might be something we could look into again when
> > we're running only on Python 3, since at that point the feature is built
> > into the language.
> >
>
> For kuryr-kubernetes we target only Python3, I wonder if we could move
> kuryr-libnetwork
> to be python3 only and, if that were the case, how this alters the
> situation for namespace
> packages.
>
>
> >
> > Doug
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/15cceea8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 26
> Date: Mon, 4 Jul 2016 16:13:28 +0800
> From: Damon Wang <damon.devops at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades
>         work status. 6/20/2016
> Message-ID:
>         <
> CABZYMH4S8tc3XxAQbgRsuE2YyDwo6rf5v2u7u0KF+wFtceRaWw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Very glad to see *Bi-weekly Upgrades Work Status*, besides, we
> (UnitedStack) are also writing a Chinese version of weekly neutron status:
>
> http://bit.ly/29nTorX
>
> We wrote from 4.3 and now have wrote 12 pieces. :-D
>
> Wei Wang
>
> 2016-06-20 21:58 GMT+08:00 Ihar Hrachyshka <ihrachys at redhat.com>:
>
> > Hi all,
> >
> > (It?s not really bi-weekly since I missed it the previous week. This
> > report is for the last 3 weeks. I will try to keep a more regular
> schedule
> > for those updates in the future.)
> >
> > OK. What?s new in neutron upgrades since last update?
> >
> > 1. For the most part, the team works on migrating existing code base to
> > using versioned objects.
> >
> > What landed:
> >
> > - base db plugin switched to objects for subnetpools:
> > https://review.openstack.org/300056
> > - get_object(s) API now allows to pass renamed fields as filters:
> > https://review.openstack.org/327249
> >
> > What?s in the queue:
> > - utilizing DNSNameServer object in the code:
> > https://review.openstack.org/326477
> > - security groups object: https://review.openstack.org/284738
> > - *PortSecurity objects: https://review.openstack.org/327257
> >
> > There are things still crafting worth mentioning:
> > - subnet adoption in db code: https://review.openstack.org/321001
> > - subnet object adjustments: https://review.openstack.org/331009
> > - address scope adoption: https://review.openstack.org/#/c/308005/
> >
> > A lot of api test coverage for sorting and pagination happened. That is
> > something that we push for before we switch resources to using objects to
> > avoid potential regressions. Things that landed:
> > - next/prev href links tests: https://review.openstack.org/318270
> > - subnet tests: https://review.openstack.org/329340
> > - subnetpools tests: https://review.openstack.org/327081
> >
> > We have a lot more related patches though, including test coverage as
> well
> > as enabling sorting/pagination for all installations. All those are
> tracked
> > under:
> >
> >
> >
> https://review.openstack.org/#/q/status:open++(topic:bug/1566514+OR+topic:bug/1591981)
> >
> > Reviews for ^ are highly welcome!
> >
> > There were other related changes that landed in master:
> > - migrated code from using private ._context attributes to .obj_context:
> > https://review.openstack.org/283616
> > - added type information to ObjectNotFound exception:
> > https://review.openstack.org/327582
> > - NetworkDhcpAgentBinding model moved to a separate module:
> > https://review.openstack.org/328452
> > - get_object() switched to using _query_model to support RBAC filtering:
> > https://review.openstack.org/#/c/326361/
> > - query filter hook added to objects:
> https://review.openstack.org/328304
> > - qos policy filtering by ?shared? field is fixed by utilizing ^:
> > https://review.openstack.org/328313
> >
> > 2. As for multinode grenade testing, there was little progress on getting
> > voting for the DVR job. This is something that I plan to tackle in the
> near
> > future.
> >
> > ===
> >
> > Team info:
> > Upgrades Subteam has the weekly meetings on Mondays, 2PM UTC, wiki page:
> > https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam
> >
> > New patches are generally tracked under the following topic:
> >
> https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db
> >
> > Ihar
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e0472273/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 27
> Date: Mon, 4 Jul 2016 01:17:29 -0700
> From: Stephen Hindle <shindle at llnw.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +
>         BiFrost integration
> Message-ID:
>         <CANPbtN_EUx_PV8FYEvQCaTR5XEKp98wik2USYfF=
> EugBFXL2jg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Steve
>
>   I'm just suggesting the bi-frost stuff allow sufficient 'hooks' for
> operators to insert site specific setup.  Not that Kolla/Bi-Frost try
> to handle 'everything'.
>
>   For instance LDAP... Horizon integration with LDAP would certainly
> be within Kolla's perview.  However, operators also use LDAP for login
> access to the host via PAM.  This is site-specific, and outside of
> Kolla's mission.
>
>   As an example of 'respecting existing configuration' - some sites
> may use OpenVSwitch for host level networking.  Kolla currently starts
> a new openvswitchdb container without checking if OpenVSwitch is
> already running - this kills the host networking.
>
>   If you'll pardon the pun, there are a 'host' of situations like
> this, where operators will have to provide
> (possibly many/detailed) site specific configurations to a bare metal
> host.  Networking, Security, Backups, Monitoring/Logging, etc.  These
> may all be subject to corporate wide policies that are non-negotiable
> and have to be followed.
>
>   Again, I realize Kolla/BiFrost can not be everything for everyone.
> I just want to suggest that we provide well documented methods for
> operators to insert site-specific roles/plays/whatever, and that we
> take care to avoid 'stepping on' things.
>
>   I have no idea as to what/how-many 'hooks' would be required.  I
> tend to think a simple 'before-bifrost' role and 'after-bifrost' role
> would be enough.  However, others may have more input on that...
> I like the idea of using roles, as that would allow you to centralize
> all your 'site-specific' bits.  This way operators don't have to
> modify the existing kolla/BiFrost stuff.
>
>
> On Sat, Jul 2, 2016 at 3:10 PM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
> > Stephen,
> >
> > Responses inline.
> >
> > On 7/1/16, 11:35 AM, "Stephen Hindle" <shindle at llnw.com> wrote:
> >
> >>Maybe I missed it - but is there a way to provide site specific
> >>configurations?  Things we will run into in the wild include:
> >>    Configuring multiple non-openstack nics
> >
> > We don?t have anything like this at present or planned.  Would you mind
> > explaining the use case?  Typically we in the Kolla community expect a
> > production deployment to only deploy OpenStack, and not other stacks on
> > top of the bare metal hardware.  This is generally considered best
> > practice at this time, unless of course your deploying something on top
> of
> > OpenStack that may need these nics.  The reason is that OpenStack itself
> > managed alongside another application doesn?t know what it doesn't know
> > and can't handle capacity management or any of a number of other things
> > required to make an OpenStack cloud operate.
> >
> >>     IPMI configuration
> >
> > BiFrost includes IPMI integration - assumption being we will just use
> > whatever BiFrost requires here for configuration.
> >
> >>     Password integration with Corporate LDAP etc.
> >
> > We have been asked several times for this functionality, and it will come
> > naturally during either Newton or Occata.
> >
> >>     Integration with existing SANs
> >
> > Cinder integrates with SANs, and in Newton, we have integration with
> > iSCSI.  Unfortunately because of some controversy around how glance
> should
> > provide images with regards to cinder, using existing SAN gear with iSCSI
> > integration as is done by Cinder may not work as expected in a HA setup.
> >
> >>     Integration with existing corporate IPAM
> >
> > No idea
> >
> >>     Corporate Security policy (firewall rules, sudo groups,
> >>hosts.allow, ssh configs,etc)
> >
> > This is environmental specific and its hard to make a promise on what we
> > could deliver in a generic way that would be usable by everyone.
> > Therefore our generic implementation will be the "bare minimum" to get
> the
> > system into an operational state.  The things listed above are outside
> the
> > "bare minimum" iiuc.
> >
> >>
> >>Thats just off the top of my head - I'm sure we'll run into others.  I
> >>tend to think the best way
> >>to approach this is to allow some sort of 'bootstrap' role, that could
> >>be populated by the
> >>operators.  This should initially be empty (Kolla specific 'bootstrap'
> >
> > Our bootstrap playbook is for launching BiFrost and bringing up the bare
> > metal machines with an SSH credential.  It appears from this thread we
> > will have another playbook to do the bare metal initialization (thiings
> > like turning off firewalld, turning on chrony, I.e. Making the bare metal
> > environment operational for OpenStack)
> >
> > I think what you want is a third playbook which really belongs in the
> > domain of the operators to handle site-specific configuration as required
> > by corporate rules and the like.
> >
> >
> >>actions should be
> >>in another role) to prevent confusion.
> >>
> >>We also have to be careful that kolla doesn't stomp on any non-kolla
> >>configuration...
> >
> > Could you expand here.  Kolla currently expects the machines under its
> > control to be only OpenStack machines, and not have other applications
> > running on them.
> >
> > Hope that was helpful.
> >
> > Regards
> > -steve
> >
> >>
> >>
> >>On Thu, Jun 30, 2016 at 12:43 PM, Mooney, Sean K
> >><sean.k.mooney at intel.com> wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Steven Dake (stdake) [mailto:stdake at cisco.com]
> >>>> Sent: Monday, June 27, 2016 9:21 PM
> >>>> To: OpenStack Development Mailing List (not for usage questions)
> >>>> <openstack-dev at lists.openstack.org>
> >>>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +
> >>>> BiFrost integration
> >>>>
> >>>>
> >>>>
> >>>> On 6/27/16, 11:19 AM, "Devananda van der Veen"
> >>>> <devananda.vdv at gmail.com>
> >>>> wrote:
> >>>>
> >>>> >At a quick glance, this sequence diagram matches what I
> >>>> >envisioned/expected.
> >>>> >
> >>>> >I'd like to suggest a few additional steps be called out, however I'm
> >>>> >not sure how to edit this so I'll write them here.
> >>>> >
> >>>> >
> >>>> >As part of the installation of Ironic, and assuming this is done
> >>>> >through Bifrost, the Actor should configure Bifrost for their
> >>>> >particular network environment. For instance: what eth device is
> >>>> >connected to the IPMI network; what IP ranges can Bifrost assign to
> >>>> >physical servers; and so on.
> >>>> >
> >>>> >There are a lot of other options during the install that can be
> >>>> >changed, but the network config is the most important. Full defaults
> >>>> >for this roles' config options are here:
> >>>> >
> >>>> >
> https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro
> >>>> s
> >>>> >t-i
> >>>> >ronic-install/defaults/main.yml
> >>>> >
> >>>> >and documentation is here:
> >>>> >
> >>>> >
> https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro
> >>>> s
> >>>> >t-i
> >>>> >ronic-install
> >>>> >
> >>>> >
> >>>> >
> >>>> >Immediately before "Ironic PXE boots..." step, the Actor must perform
> >>>> >an action to "enroll" hardware (the "deployment targets") in Ironic.
> >>>> >This could be done in several ways: passing a YAML file to Bifrost;
> >>>> >using the Ironic CLI; or something else.
> >>>> >
> >>>> >
> >>>> >"Ironic reports success to the bootstrap operation" is ambiguous.
> >>>> >Ironic does not currently support notifications, so, to learn the
> >>>> >status of the deployments, you will need to poll the Ironic API (eg,
> >>>> >"ironic node-list").
> >>>> >
> >>>>
> >>>> Great,
> >>>>
> >>>> Thanks for the feedback.  I'll integrate your changes into the
> sequence
> >>>> diagram when I have a free hour or so - whenever that is :)
> >>>>
> >>>> Regards
> >>>> -steve
> >>> [Mooney, Sean K] I agree with most of devananda points and had come to
> >>>similar
> >>> Conlcutions.
> >>>
> >>> At a highlevel I think the workflow from 0 to cloud would be as follow.
> >>> Assuming you have one linux system.
> >>> - clone http://github.com/openstack/kolla && cd kolla
> >>> - tools/kolla-host build-host-deploy
> >>>         This will install ansible if not installed then invoke a
> >>>playbook to install
> >>>         All build dependencies and generate the kolla-build.conf
> >>>passwords.yml and global.yml.
> >>>      Install kolla python package
> >>> - configure kolla-build.conf as required
> >>> - tools/build.py or kolla-build to build image
> >>> - configure global.yml and or biforst specific file
> >>>   This would involve specifying a file that can be used with bifrost
> >>>dynamic inventory.
> >>>   Configuring network interface for bifrost to use.
> >>>   Enable ssh-key generate or supply one to use as the key to us when
> >>>connecting to the servers post deploy.
> >>>   Configure diskimage builder options or supply path to a file on the
> >>>system to use as your os image.
> >>> - tools/kolla-host deploy-bifrost
> >>>   Deploys bifrost container.
> >>>   Copies images/keys
> >>>   Bootstraps bifrost and start services.
> >>> - tools/kolla-host deploy-servers
> >>>   Invokes bifrost enroll and deploy dynamic then polls until all
> >>>   Servers are provisioned or a server fails.
> >>> - tools/kolla-hosts bootstrap-servers
> >>>   Installs all kolla deploy dependencies
> >>>   Docker ect. This will also optionally do things such as
> >>>   Configure hugepages, configure cpu isolation, firewall settings
> >>>   Or any other platform level config for example apply labels to ceph
> >>>   Disks .
> >>>   This role will reboot the remote server at the end of the role if
> >>>required
> >>>   e.g. after installing The wily kernel on Ubuntu 14.04
> >>> - configure global.yml as normal
> >>> - tools/kolla-ansible prechecks (this should now pass)
> >>> - tools/kolla-ansible deploy
> >>> - profit
> >>>
> >>> I think this largely agrees with the diagram you proposed but has a
> >>>couple of extra steps/details.
> >>>
> >>>>
> >>>> >
> >>>> >
> >>>> >Cheers,
> >>>> >--Devananda
> >>>> >
> >>>> >On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:
> >>>> >> Hey folks,
> >>>> >>
> >>>> >> I created the following sequence diagram to show my thinking on
> >>>> >>Ironic  integration.  I recognize some internals of the recently
> >>>> >>merged bifrost changes  are not represented in this diagram.  I
> would
> >>>> >>like to see a bootstrap action do  all of the necessary things to
> >>>> >>bring up BiFrost in a container using Sean's WIP  Kolla patch
> >>>> followed
> >>>> >>by bare metal minimal OS load followed by Kolla dependency  software
> >>>> >>(docker-engine, docker-py, and ntpd) loading and initialization.
> >>>> >>
> >>>> >> This diagram expects ssh keys to be installed on the deployment
> >>>> >>targets via BiFrost.
> >>>> >>
> >>>> >>
> https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D
> >>>> >>
> >>>> >> Thoughts welcome, especially from folks in the Ironic community or
> >>>> >>Sean who is  leading this work in Kolla.
> >>>> >>
> >>>> >> Regards,
> >>>> >> -steve
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>
> >>>>
> >>_____________________________________________________________________
> >>>> _
> >>>> >>___
> >>>> >>_
> >>>> >> OpenStack Development Mailing List (not for usage questions)
> >>>> >> Unsubscribe:
> >>>> >>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >>
> >>>> >
> >>>>
> >______________________________________________________________________
> >>>> _
> >>>> >___ OpenStack Development Mailing List (not for usage questions)
> >>>> >Unsubscribe:
> >>>> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>>
> _______________________________________________________________________
> >>>> ___
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe: OpenStack-dev-
> >>>> request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
>
> >>>_________________________________________________________________________
> >>>_
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>--
> >>Stephen Hindle - Senior Systems Engineer
> >>480.807.8189 480.807.8189
> >>www.limelight.com Delivering Faster Better
> >>
> >>Join the conversation
> >>
> >>at Limelight Connect
> >>
> >>--
> >>The information in this message may be confidential.  It is intended
> >>solely
> >>for
> >>the addressee(s).  If you are not the intended recipient, any disclosure,
> >>copying or distribution of the message, or any action or omission taken
> >>by
> >>you
> >>in reliance on it, is prohibited and may be unlawful.  Please immediately
> >>contact the sender if you have received this message in error.
> >>
> >>
>
> >>__________________________________________________________________________
> >>OpenStack Development Mailing List (not for usage questions)
> >>Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Stephen Hindle - Senior Systems Engineer
> 480.807.8189 480.807.8189
> www.limelight.com Delivering Faster Better
>
> Join the conversation
>
> at Limelight Connect
>
> --
> The information in this message may be confidential.  It is intended solely
> for
> the addressee(s).  If you are not the intended recipient, any disclosure,
> copying or distribution of the message, or any action or omission taken by
> you
> in reliance on it, is prohibited and may be unlawful.  Please immediately
> contact the sender if you have received this message in error.
>
>
>
>
> ------------------------------
>
> Message: 28
> Date: Mon, 4 Jul 2016 16:02:53 +0800
> From: hu.zhijiang at zte.com.cn
> To: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka
>         requirementssupported by CentOS
> Message-ID:
>         <
> OF685C0E9F.8AD230D6-ON48257FE6.002BD37A-48257FE6.002C2309 at zte.com.cn>
> Content-Type: text/plain; charset="utf-8"
>
> > As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> > It's proven very hard to prevent EPEL pushing broken updates, or push
> > updates to fit OpenStack requirements.
>
> > Actually, all the dependency above but ansible, docker and git python
> > modules are in CentOS Cloud SIG repositories.
> > If you are interested to work w/ CentOS Cloud SIG, we can add missing
> > dependencies in our repositories.
>
> I added [kolla] key word in the mail subject. Hope can get response from
> Kolla team about how to choose repos.
>
>
> Thanks,
> Zhijiang
>
>
>
> ???:         Ha?kel <hguemar at fedoraproject.org>
> ???:         "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>,
> ??:   2016-07-03 05:18
> ??:   [probably forge email???????]Re: [openstack-dev]
> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS
>
>
>
> 2016-07-02 20:42 GMT+02:00 jason <huzhijiang at gmail.com>:
> > Pip Package Name Supported By Centos CentOS Name Repo Name
> >
>
> ======================================================================================================================
> > ansible                   yes
> > ansible1.9.noarch                epel
> > docker-py              yes
> > python-docker-py.noarch    extras
> > gitdb                      yes
> > python-gitdb.x86_64            epel
> > GitPython              yes
> > GitPython.noarch                epel
> > oslo.config             yes
> > python2-oslo-config.noarch centos-openstack-mitaka
> > pbr                        yes
> > python-pbr.noarch               epel
> > setuptools             yes
> > python-setuptools.noarch    base
> > six                         yes
> > python-six.noarch                 base
> > pycrypto                yes
> > python2-crypto                      epel
> > graphviz                no
> > Jinja2                    no (Note: Jinja2 2.7.2 will be installed as
> > dependency by ansible)
> >
>
> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> It's proven very hard to prevent EPEL pushing broken updates, or push
> updates to fit OpenStack requirements.
>
> Actually, all the dependency above but ansible, docker and git python
> modules are in CentOS Cloud SIG repositories.
> If you are interested to work w/ CentOS Cloud SIG, we can add missing
> dependencies in our repositories.
>
>
> >
> > As above table shows, only two (graphviz and Jinja2) are not supported
> > by centos currently. As those not supported packages are definitly not
> > used by OpenStack as well as Daisy. So basicaly we can use pip to
> > install them after installing other packages by yum. But note that
> > Jinja2 2.7.2 will be installed as dependency while yum install
> > ansible, so we need to using pip to install jinja2 2.8 after that to
> > overide the old one. Also note that we must make sure pip is ONLY used
> > for installing those two not supported packages.
> >
> > But before you trying to use pip, please consider these:
> >
> > 1) graphviz is just for saving image depend graph text file and is not
> > used by default and only used in build process if it is configured to
> > be used.
> >
> > 2) Jinja2 rpm can be found at
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
> > think is suitable for CentOS. I have tested it.
> >
> > So, as far as Kolla deploy process concerned, there is no need to use
> > pip to install graphviz and Jinja2. Further more, if we do not install
> > Kolla either then we can get ride of pip totally!
> >
> > I encourage all of you to think about not using pip any more for
> > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
> > may be overide back and force if not using them carefully. So not
> > using pip will make things easier and make jump server more cleaner.
> > Any ideas?
> >
> >
> > Thanks,
> > Zhijiang
> >
> > --
> > Yours,
> > Jason
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential
> and is intended for the exclusive use of the addressee(s).  If you are not
> an intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/5317a4dc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Mon, 4 Jul 2016 16:36:30 +0800
> From: Gerard Braad <me at gbraad.nl>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka
>         requirementssupported by CentOS
> Message-ID:
>         <
> CAGrH30XrpdS2D8UvPdcSMfMdJM1ExsKysaX_f0gLa4miUyf6oQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> > ???:         Ha?kel <hguemar at fedoraproject.org>
> > As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> > It's proven very hard to prevent EPEL pushing broken updates, or push
> > updates to fit OpenStack requirements.
> > Actually, all the dependency above but ansible, docker and git python
> > modules are in CentOS Cloud SIG repositories.
> > If you are interested to work w/ CentOS Cloud SIG, we can add missing
> > dependencies in our repositories.
>
> Interesting point, as currently the preference is to use docker
> project's provided
> packages for installing. This means that `docker-storage-setup` is not
> available.
> This can actually be very helpful for CentOS-based deployments to get a
> production-ready environment setup.
>
>
> Gerard
>
> --
>
>    Gerard Braad | http://gbraad.nl
>    [ Doing Open Source Matters ]
>
>
>
> ------------------------------
>
> Message: 30
> Date: Mon, 4 Jul 2016 16:35:00 +0800
> From: hu.zhijiang at zte.com.cn
> To: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] ??: [probably forge email???????]Re:
>         [daisycloud-core] Kolla Mitaka requirementssupported by CentOS
> Message-ID:
>         <
> OFCB261F89.4C7A08C6-ON48257FE6.002EC1D3-48257FE6.002F1386 at zte.com.cn>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Ha?kel
>
> > Actually, all the dependency above but ansible, docker and git python
> > modules are in CentOS Cloud SIG repositories.
> > If you are interested to work w/ CentOS Cloud SIG, we can add missing
> > dependencies in our repositories.
>
> So currently Jinja2 version >= 2.8 is already in the  CentOS Cloud SIG
> repository. could you please point a way to get it? That will be a great
> help for us to use kolla, because currenly we are using fedora repo
> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506 to get
> Jinja2 version >= 2.8, but we are sure that  CentOS Cloud SIG repository
> will be a more better choise than fedora repo.
>
>
>
>
> ???:         Ha?kel <hguemar at fedoraproject.org>
> ???:         "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>,
> ??:   2016-07-03 05:18
> ??:   [probably forge email???????]Re: [openstack-dev]
> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS
>
>
>
> 2016-07-02 20:42 GMT+02:00 jason <huzhijiang at gmail.com>:
> > Pip Package Name Supported By Centos CentOS Name Repo Name
> >
>
> ======================================================================================================================
> > ansible                   yes
> > ansible1.9.noarch                epel
> > docker-py              yes
> > python-docker-py.noarch    extras
> > gitdb                      yes
> > python-gitdb.x86_64            epel
> > GitPython              yes
> > GitPython.noarch                epel
> > oslo.config             yes
> > python2-oslo-config.noarch centos-openstack-mitaka
> > pbr                        yes
> > python-pbr.noarch               epel
> > setuptools             yes
> > python-setuptools.noarch    base
> > six                         yes
> > python-six.noarch                 base
> > pycrypto                yes
> > python2-crypto                      epel
> > graphviz                no
> > Jinja2                    no (Note: Jinja2 2.7.2 will be installed as
> > dependency by ansible)
> >
>
> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> It's proven very hard to prevent EPEL pushing broken updates, or push
> updates to fit OpenStack requirements.
>
> Actually, all the dependency above but ansible, docker and git python
> modules are in CentOS Cloud SIG repositories.
> If you are interested to work w/ CentOS Cloud SIG, we can add missing
> dependencies in our repositories.
>
>
> >
> > As above table shows, only two (graphviz and Jinja2) are not supported
> > by centos currently. As those not supported packages are definitly not
> > used by OpenStack as well as Daisy. So basicaly we can use pip to
> > install them after installing other packages by yum. But note that
> > Jinja2 2.7.2 will be installed as dependency while yum install
> > ansible, so we need to using pip to install jinja2 2.8 after that to
> > overide the old one. Also note that we must make sure pip is ONLY used
> > for installing those two not supported packages.
> >
> > But before you trying to use pip, please consider these:
> >
> > 1) graphviz is just for saving image depend graph text file and is not
> > used by default and only used in build process if it is configured to
> > be used.
> >
> > 2) Jinja2 rpm can be found at
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
> > think is suitable for CentOS. I have tested it.
> >
> > So, as far as Kolla deploy process concerned, there is no need to use
> > pip to install graphviz and Jinja2. Further more, if we do not install
> > Kolla either then we can get ride of pip totally!
> >
> > I encourage all of you to think about not using pip any more for
> > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
> > may be overide back and force if not using them carefully. So not
> > using pip will make things easier and make jump server more cleaner.
> > Any ideas?
> >
> >
> > Thanks,
> > Zhijiang
> >
> > --
> > Yours,
> > Jason
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential
> and is intended for the exclusive use of the addressee(s).  If you are not
> an intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a220fac9/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 31
> Date: Mon, 4 Jul 2016 09:40:22 +0100
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>,
>         "openstack-operators at lists.openstack.org"
>         <openstack-operators at lists.openstack.org>
> Subject: Re: [openstack-dev] [Openstack-operators] [nova] Fail build
>         request if we can't inject files?
> Message-ID: <20160704084021.GA3763 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote:
> > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it
> runs
> > ssh validation + neutron + config drive + metadata service, which will
> test
> > the virtual device tagging 2.32 microversion API (added last week).
> >
> > The job has a file injection test that fails consistently which is
> keeping
> > it from being voting.
> >
> > After debugging, the problem is the files to inject are silently ignored
> > because n-cpu is configured with libvirt.inject_partition=-2 by default.
> > That disables file injection:
> >
> >
> https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030
> >
> > We don't even log a warning if the user requested files to inject and we
> > can't honor it. If I were a user and tried to inject files when creating
> a
> > server but they didn't show up in the guest, I'd open a support ticket
> > against my cloud provider. So I don't think a warning (that only the
> admin
> > sees) is sufficient here. This isn't something that's discoverable from
> the
> > API either, it's really host configuration / capability (something we
> still
> > need to tackle).
>
> Won't the user provided files also get made available by the config drive /
> metadata service ?  I think that's the primary reason for file injection
> not
> being a fatal problem. Oh that and the fact that we've wanted to kill it
> for
> at least 3 years now :-)
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
>
>
> ------------------------------
>
> Message: 32
> Date: Mon, 04 Jul 2016 11:16:09 +0200
> From: Julien Danjou <julien at danjou.info>
> To: Denis Makogon <lildee1991 at gmail.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python
>         clients
> Message-ID: <m04m85bw6e.fsf at danjou.info>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, Jun 26 2016, Denis Makogon wrote:
>
> > I know that some work in progress to bring Python 3.4 compatibility to
> > backend services and it is kinda hard question to answer, but i'd like to
> > know if there are any plans to support asynchronous HTTP API client in
> the
> > nearest future using aiohttp [1] (PEP-3156)?
>
> I don't think there is unfortunately. Most clients now relies on
> `requests', and unfortunately it's not async not it seems ready to be
> last time I checked.
>
> --
> Julien Danjou
> // Free Software hacker
> // https://julien.danjou.info
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 800 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a07dc24c/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 33
> Date: Mon, 4 Jul 2016 11:17:40 +0200
> From: Sergii Golovatiuk <sgolovatiuk at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel
>         Library Core
> Message-ID:
>         <CA+HkNVup=8XN9cRU-Te7B13G5TM8LP=c7FLWskqte=
> fyOBQMBg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Please welcome Maksim as he's just joined fuel-library Core Team!
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Jun 28, 2016 at 1:06 PM, Adam Heczko <aheczko at mirantis.com> wrote:
>
> > Although I'm not Fuel core, +1 from me to Maksim. Maksim is not only
> > excellent engineer but also very friendly and helpful folk.
> >
> > On Tue, Jun 28, 2016 at 12:19 PM, Georgy Kibardin <
> gkibardin at mirantis.com>
> > wrote:
> >
> >> +1
> >>
> >> On Tue, Jun 28, 2016 at 1:12 PM, Kyrylo Galanov <kgalanov at mirantis.com>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn <
> >>> mmosesohn at mirantis.com> wrote:
> >>>
> >>>> +1. Maksim is an excellent reviewer.
> >>>>
> >>>> On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz <aschultz at mirantis.com>
> >>>> wrote:
> >>>> > +1
> >>>> >
> >>>> > On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya <
> >>>> bdobrelia at mirantis.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
> >>>> >> > I am very sorry for sending without subject. I am adding subject
> to
> >>>> >> > voting and my +1
> >>>> >>
> >>>> >> +1 from my side!
> >>>> >>
> >>>> >> >
> >>>> >> > --
> >>>> >> > Best regards,
> >>>> >> > Sergii Golovatiuk,
> >>>> >> > Skype #golserge
> >>>> >> > IRC #holser
> >>>> >> >
> >>>> >> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk
> >>>> >> > <sgolovatiuk at mirantis.com <mailto:sgolovatiuk at mirantis.com>>
> >>>> wrote:
> >>>> >> >
> >>>> >> >     Hi,
> >>>> >> >
> >>>> >> >     I would like to nominate Maksim Malchuk to Fuel-Library Core
> >>>> team.
> >>>> >> >     He?s been doing a great job so far [0]. He?s #2 reviewer and
> #2
> >>>> >> >     contributor with 28 commits for last 90 days [1][2].
> >>>> >> >
> >>>> >> >     Fuelers, please vote with +1/-1 for approval/objection.
> Voting
> >>>> will
> >>>> >> >     be open until July of 4th. This will go forward after voting
> is
> >>>> >> >     closed if there are no objections.
> >>>> >> >
> >>>> >> >     Overall contribution:
> >>>> >> >     [0] http://stackalytics.com/?user_id=mmalchuk
> >>>> >> >     Fuel library contribution for last 90 days:
> >>>> >> >     [1]
> >>>> >> > <http://stackalytics.com/report/contribution/fuel-library/90>
> >>>> http://stackalytics.com/report/contribution/fuel-library/90
> >>>> >> >         http://stackalytics.com/report/users/mmalchuk
> >>>> >> >     List of reviews:
> >>>> >> >     [2]
> >>>> >> >
> >>>>
> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
> >>>> >> >     --
> >>>> >> >     Best regards,
> >>>> >> >     Sergii Golovatiuk,
> >>>> >> >     Skype #golserge
> >>>> >> >     IRC #holser
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>>
> __________________________________________________________________________
> >>>> >> > OpenStack Development Mailing List (not for usage questions)
> >>>> >> > Unsubscribe:
> >>>> >> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >> >
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Best regards,
> >>>> >> Bogdan Dobrelya,
> >>>> >> Irc #bogdando
> >>>> >>
> >>>> >>
> >>>>
> __________________________________________________________________________
> >>>> >> OpenStack Development Mailing List (not for usage questions)
> >>>> >> Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>>
> __________________________________________________________________________
> >>>> > OpenStack Development Mailing List (not for usage questions)
> >>>> > Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >
> >>>>
> >>>>
> >>>>
> __________________________________________________________________________
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > Adam Heczko
> > Security Engineer @ Mirantis Inc.
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8cbfe82f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 34
> Date: Mon, 4 Jul 2016 12:36:30 +0300
> From: Denis Makogon <lildee1991 at gmail.com>
> To: Denis Makogon <lildee1991 at gmail.com>,  "OpenStack Development
>         Mailing List (not for usage questions)"
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python
>         clients
> Message-ID:
>         <CALzSdtnQtzUNCjP+6u4GO=qNesD0q+KZPDZ7=
> QmSGcrG7oqr9A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-07-04 12:16 GMT+03:00 Julien Danjou <julien at danjou.info>:
>
> > On Sun, Jun 26 2016, Denis Makogon wrote:
> >
> > > I know that some work in progress to bring Python 3.4 compatibility to
> > > backend services and it is kinda hard question to answer, but i'd like
> to
> > > know if there are any plans to support asynchronous HTTP API client in
> > the
> > > nearest future using aiohttp [1] (PEP-3156)?
> >
> > I don't think there is unfortunately. Most clients now relies on
> > `requests', and unfortunately it's not async not it seems ready to be
> > last time I checked.
> >
> >
> Unfortunately, it is what it is. So, i guess this is something that is
> worth considering discuss during summit and find the way and capacity to
> support async HTTP API during next release. I'll start work on general
> concept that would satisfy both 2.7 and 3.4 or greater Python versions.
>
> What would be the best place to submit spec?
>
>
> --
> > Julien Danjou
> > // Free Software hacker
> > // https://julien.danjou.info
> >
>
> Kind regards,
> Denys Makogon
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e88a5547/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 51, Issue 6
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/2f40a259/attachment-0001.html>


More information about the OpenStack-dev mailing list