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