Open Stack

Thank you for your clarification.

Would you file a bug on this when you get a chance?

https://bugs.launchpad.net/tricircle/

On Tue, Jul 5, 2016 at 8:39 PM, Luck Dog <dfhuangg at gmail.com> wrote:

> Hello,
>
> The problem has been solved now. I add a new line to
>
> the file local.conf. The content of the added line is
>
> “NEUTRON_CREATE_INITIAL_NETWORKS=False”, By adding this line
>
> Devstack won’t create default network, and it will use the configuration
>
> set manually. Without this line, Devstack will create initial network
>
> elements including external network. However, This external network
>
> is not supported by single node. If it runs on a single node then
>
> some errors will turn up. It is exactly the error I met.
>
>
> @ Shinobu, The  attachment is the old local.conf. it is from the official
>
> net page, and the URL is
> https://github.com/openstack/tricircle/blob/master/devstack/local.conf.sample
>
> thanks for your kindness!
>
> 2016-07-05 14:58 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: [kuryr] kuryr-libnetwork split (Vikas Choudhary)
>>    2. Re: [mistral] [murano] [yaql] yaqluator bug (Renat Akhmerov)
>>    3. Re: [mistral] [murano] [yaql] yaqluator bug (Stan Lagun)
>>    4. Re: [nova] Non-priority feature freeze and FFEs (Claudiu Belu)
>>    5. Re: OpenStack-dev Digest, Vol 51, Issue 6 (Shinobu Kinjo)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 5 Jul 2016 10:11:04 +0530
>> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
>> To: Antoni Segura Puimedon <toni+openstackml at midokura.com>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>         <openstack-dev at lists.openstack.org>, Irena Berezovsky
>>         <irena at midokura.com>
>> Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split
>> Message-ID:
>>         <
>> CABJxuZrVDTaTHHBxs4RNuLq30n04KBbhuk7gKEdWXDCC8ggvxA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello Everybody !!!
>>
>> As we discussed in the meeting yesterday, I have submitted restructured
>> patches now in kuryr-lib and kuryr-libnetwork to address only dropping
>> non-relevant code and adding kuryr-lib as dependency to kuryr-libnetwork.
>>
>> Please provide review comments so that i quickly reiterate over patches
>> and
>> eventually we will be able to move our existing under review patches also
>> from kuryr to kuryr-libnetwork.
>>
>> Since RPC support is also ready, will be submitting the same in both repos
>> as seperate patches(linked with dependency)
>>
>> Here is the link for base patchsets:
>> Kuryr-libnetwork:  https://review.openstack.org/#/c/337350/
>> kuryr-lib: https://review.openstack.org/#/c/336784/
>>
>>
>>
>> Regards
>> Vikas
>>
>> On Fri, Jul 1, 2016 at 6:40 PM, Antoni Segura Puimedon <
>> toni+openstackml at midokura.com> wrote:
>>
>> > Hi fellow kuryrs!
>> >
>> > In order to proceed with the split of kuryr into a main lib and it's
>> kuryr
>> > libnetwork component, we've cloned the contents of openstack/kuryr over
>> to
>> > openstack/kuryr-libnetwork.
>> >
>> > The idea is that after this, the patches that will go to openstack/kuryr
>> > will be to trim out the kuryr/kuryr-libnetwork specific parts and make a
>> > release of the common parts so that openstack/kuryr-libnetwork can start
>> > using it.
>> >
>> > I propose that we use python namespaces and the current common code in
>> > kuryr is moved to:
>> > kuryr/lib/
>> >
>> >
>> > which openstack/kuryr-libnetwork would import like so:
>> >
>> >     from kuryr.lib import binding
>> >
>> > So, right now, patches in review that are for the Docker ipam or remote
>> > driver, should be moved to openstack/kuryr-libnetwork and soon we should
>> > make openstack/kuryr-libnetwork add kuryr-lib to the requirements.
>> >
>> > Regards,
>> >
>> > Toni
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/0d032a4c/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 Jul 2016 12:07:25 +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] [murano] [yaql] yaqluator bug
>> Message-ID: <E9ADF691-7387-47EB-86F5-2A3EEFCF3291 at gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> If I understand the meaning of ?join? function correctly then from user
>> perspective this behavior in Mistral and Yaqluator is a bug because we?re
>> joining two collections similar to how it works in SQL so the correct
>> result should be:
>>
>> [[1, 3], [2, 3]]
>>
>> I.e. collection consisting of two collections where each element if the
>> first one is combined with each element of the second one.
>>
>> If so, we need to fix this in both Mistral and Yaqluator.
>>
>>
>> Alex, Stan, do you agree?
>>
>> Renat Akhmerov
>> @Nokia
>>
>> > On 28 Jun 2016, at 23:46, Elisha, Moshe (Nokia - IL) <
>> moshe.elisha at nokia.com> wrote:
>> >
>> > Hi,
>> >
>> > Thank you for the kind words, Alexey.
>> >
>> > I was able to reproduce your bug and I have also found the issue.
>> >
>> > The problem is that we did not create the parser with the
>> engine_options used in the yaql library by default when using the CLI.
>> > Specifically, the "yaql.limitIterators" was missing? I am not sure that
>> this settings should have this affect but maybe the Yaql guys can comment
>> on that.
>> >
>> > If we will change yaqluator to use this setting it will mean that
>> yaqluator will not be consistent with Mistral because Mistral is using YAQL
>> without this engine option (If I use your example in a workflow, Mistral
>> returns exactly like the yaqluator returns)
>> >
>> >
>> > Workflow:
>> >
>> >> ---
>> >> version: '2.0'
>> >>
>> >> test_yaql:
>> >>   tasks:
>> >>     test_yaql:
>> >>       action: std.noop
>> >>       publish:
>> >>         output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>> >
>> > Workflow result:
>> >
>> >
>> > [root at s53-19 ~(keystone_admin)]# mistral task-get-published
>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>> > {
>> >     "output_expr": [
>> >         [
>> >             1,
>> >             3
>> >         ]
>> >     ]
>> > }
>> >
>> >
>> > As Matthews pointed out, the yaqluator is indeed OpenSource and
>> contributions are welcomed.
>> >
>> > [1]
>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>> <
>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>> >
>> >
>> >
>> >
>> > From: Dougal Matthews <dougal at redhat.com <mailto:dougal at redhat.com>>
>> > Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)" <openstack-dev at lists.openstack.org <mailto:
>> openstack-dev at lists.openstack.org>>
>> > Date: Monday, 27 June 2016 at 16:44
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org <mailto:
>> openstack-dev at lists.openstack.org>>
>> > Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>> >
>> > On 27 June 2016 at 14:30, Alexey Khivin <akhivin at gmail.com <mailto:
>> akhivin at gmail.com>> wrote:
>> >> Hello, Moshe
>> >>
>> >> Tomorrow I discovered yaqluator.com <http://yaqluator.com/> for
>> myself! Thanks for the useful tool!
>> >>
>> >> But suddenly I was said that the expression
>> >> [1,2].join([3], true, [$1, $2])
>> >> evaluated to [[1,3]] on the yaqluator
>> >>
>> >> A the same time this expression evaluated right when I using raw yaql
>> interpreter.
>> >>
>> >> Could we fix this issue?
>> >>
>> >> By the way, don't you want to make yaqluator opensource? If you would
>> transfer yaqluator to Openstack Foundation, then  community will be able to
>> fix such kind of bugs
>> >
>> > It looks like it is open source, there is a link in the footer:
>> https://github.com/ALU-CloudBand/yaqluator <
>> https://github.com/ALU-CloudBand/yaqluator>
>> >
>> >>
>> >> Thank you!
>> >> Best regards, Alexey Khivin
>> >>
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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/20160705/4977ab22/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 4 Jul 2016 22:12:55 -0700
>> From: Stan Lagun <slagun at mirantis.com>
>> To: "Elisha, Moshe (Nokia - IL)" <moshe.elisha at nokia.com>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>         <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>> Message-ID:
>>         <CAOCoZia=zLQqn54mwjk2me0H2KXfeqa-J6=
>> x3iAKz+sxO+k3Pg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi!
>>
>> The issue with join is just a yaql bug that is already fixed. The problem
>> with yaqluator is that it doesn't use the latest yaql library.
>>
>> Another problem is that it does't sets options correctly. As a result it
>> is
>> possible to bring the site down with a query that produces endless
>> collection
>>
>> Sincerely yours,
>> Stan Lagun
>> Principal Software Engineer @ Mirantis
>>
>> <slagun at mirantis.com>
>>
>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
>> moshe.elisha at nokia.com> wrote:
>>
>> > Hi,
>> >
>> > Thank you for the kind words, Alexey.
>> >
>> > I was able to reproduce your bug and I have also found the issue.
>> >
>> > The problem is that we did not create the parser with the engine_options
>> > used in the yaql library by default when using the CLI.
>> > Specifically, the "yaql.limitIterators" was missing? I am not sure that
>> > this settings should have this affect but maybe the Yaql guys can
>> comment
>> > on that.
>> >
>> > If we will change yaqluator to use this setting it will mean that
>> > yaqluator will not be consistent with Mistral because Mistral is using
>> YAQL
>> > without this engine option (If I use your example in a workflow, Mistral
>> > returns exactly like the yaqluator returns)
>> >
>> >
>> > Workflow:
>> >
>> > ---
>> > version: '2.0'
>> >
>> > test_yaql:
>> >   tasks:
>> >     test_yaql:
>> >       action: std.noop
>> >       publish:
>> >         output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>> >
>> >
>> > Workflow result:
>> >
>> >
>> > [root at s53-19 ~(keystone_admin)]# mistral task-get-published
>> > 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>> > {
>> >     "output_expr": [
>> >         [
>> >             1,
>> >             3
>> >         ]
>> >     ]
>> > }
>> >
>> >
>> > As Matthews pointed out, the yaqluator is indeed OpenSource and
>> > contributions are welcomed.
>> >
>> > [1]
>> >
>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>> >
>> >
>> >
>> > From: Dougal Matthews <dougal at redhat.com>
>> > Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)" <
>> > openstack-dev at lists.openstack.org>
>> > Date: Monday, 27 June 2016 at 16:44
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> > openstack-dev at lists.openstack.org>
>> > Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>> >
>> > On 27 June 2016 at 14:30, Alexey Khivin <akhivin at gmail.com> wrote:
>> >
>> >> Hello, Moshe
>> >>
>> >> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
>> >> tool!
>> >>
>> >> But suddenly I was said that the expression
>> >> [1,2].join([3], true, [$1, $2])
>> >> evaluated to [[1,3]] on the yaqluator
>> >>
>> >> A the same time this expression evaluated right when I using raw yaql
>> >> interpreter.
>> >>
>> >> Could we fix this issue?
>> >>
>> >> By the way, don't you want to make yaqluator opensource? If you would
>> >> transfer yaqluator to Openstack Foundation, then  community will be
>> able to
>> >> fix such kind of bugs
>> >>
>> >
>> > It looks like it is open source, there is a link in the footer:
>> > https://github.com/ALU-CloudBand/yaqluator
>> >
>> >
>> >>
>> >> Thank you!
>> >> Best regards, Alexey Khivin
>> >>
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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/fe707c06/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 5 Jul 2016 06:26:38 +0000
>> From: Claudiu Belu <cbelu at cloudbasesolutions.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>         <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and
>>         FFEs
>> Message-ID:
>>         <FBEE3301F14DA946B921457EF854C37742E82761 at CBSEX1.cloudbase.local>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi,
>>
>> The Hyper-V implementation of the bp virt-device-role-tagging is
>> mergeable [1]. The patch is quite simple, it got some reviews, and the
>> tempest test test_device_tagging [2] passed. [3]
>>
>> [1] https://review.openstack.org/#/c/331889/
>> [2] https://review.openstack.org/#/c/305120/
>> [3]
>> http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz
>>
>> Best regards,
>>
>> Claudiu Belu
>>
>> ________________________________________
>> From: Markus Zoeller [mzoeller at linux.vnet.ibm.com]
>> Sent: Monday, July 04, 2016 2:24 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs
>>
>> On 01.07.2016 23:03, Matt Riedemann wrote:
>> > We're now past non-priority feature freeze. I've started going through
>> > some blueprints and -2ing them if they still have outstanding changes. I
>> > haven't gone through the full list yet (we started with 100).
>> >
>> > I'm also building a list of potential FFE candidates based on:
>> >
>> > 1. How far along the change is (how ready is it?), e.g. does it require
>> > a lot of change yet? Does it require a Tempest test and is that passing
>> > already? How much of the series has already merged and what's left?
>> >
>> > 2. How much core reviewer attention has it already gotten?
>> >
>> > 3. What kind of priority does it have, i.e. if we don't get it done in
>> > Newton do we miss something in Ocata? Think things that start
>> > deprecation/removal timers.
>> >
>> > The plan is for the nova core team to have an informal meeting in the
>> > #openstack-nova IRC channel early next week, either Tuesday or
>> > Wednesday, and go through the list of potential FFE candidates.
>> >
>> > Blueprints that get exceptions will be checked against the above
>> > criteria and who on the core team is actually going to push the changes
>> > through.
>> >
>> > I'm looking to get any exceptions completed within a week, so targeting
>> > Wednesday 7/13. That leaves a few days for preparing for the meetup.
>> >
>>
>> FWIW, bp "libvirt-virtlogd" [1] is basically ready to merge. The two
>> changes [2] and [3] did already get a lot of attention from danpb.
>>
>> References:
>> [1]
>> https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd
>> [2] https://review.openstack.org/#/c/334480/
>> [3] https://review.openstack.org/#/c/323765/
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 5 Jul 2016 15:58:24 +0900
>> From: Shinobu Kinjo <shinobu.kj at gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>         <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] OpenStack-dev Digest, Vol 51, Issue 6
>> Message-ID:
>>         <CAFdRU713mdpLDwbdD=xaRMkOPO=
>> UVFF0YQY9x_Ef2dqZmXEp6A at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Would you attach local.conf you're using?
>>
>>
>> On Tue, Jul 5, 2016 at 11:51 AM, Luck Dog <dfhuangg at gmail.com> wrote:
>>
>> > 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
>> >> ********************************************
>> >>
>> >
>> >
>> >
>> __________________________________________________________________________
>> > 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
>> >
>> >
>>
>>
>> --
>> Email:
>> shinobu at linux.com
>> shinobu at redhat.com
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/51fe3162/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 9
>> ********************************************
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Email:
shinobu at linux.com
shinobu at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160706/b9b697ae/attachment-0001.html>