Open Stack

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
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/dd0cbcd9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local.conf
Type: application/octet-stream
Size: 1435 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/dd0cbcd9/attachment-0001.obj>