settingsLogin | Registersettings

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

0 votes

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:networktype': u'flat', u'name': u'public',
u'provider:physical
network': u'public', u'adminstateup': True}}^[[00m
^[[00;33mfrom (pid=29980) preparerequestbody
/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) makereservation
/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.innerexc
^[[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.forcereraise()
^[[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 forcereraise
^[[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/oslodb/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 createnetwork
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m is
external =
self.ensureazsetforexternalnetwork(netdata)
^[[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
azsetforexternalnetwork
^[[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 requestids:
['req-e97f6276-8e19-408b-829a-004a31256453']
lib/neutron
plugins/services/l3:createneutroninitialnetwork:203
lib/neutron
plugins/services/l3:createneutroninitialnetwork: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@lists.openstack.org:

Send OpenStack-dev mailing list submissions to
openstack-dev@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@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@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)

    1. [kolla][horizon] Out of branch horizon plugins? (Dave Walker)
    2. Re: New Python35 Jobs coming (Clint Byrum)
    3. [Kolla] [docker] Storage-driver and loopback usage? (Gerard Braad)
    4. Re: [grenade] upgrades vs rootwrap (Angus Lees)
    5. [keystone] spec freeze on july 8th, 2016 (Steve Martinelli)
    6. Re: [Kolla] [docker] Storage-driver and loopback usage?
      (Jeffrey Zhang)
    7. Re: [stable][all] Tagging kilo-eol for "the world"
      (Joshua Hesketh)
    8. Re: New Python35 Jobs coming (Andreas Jaeger)
    9. Re: New Python35 Jobs coming (Denis Makogon)
    10. Re: [Nova] Questions about instance actions' update and
      finish (Zhenyu Zheng)
    11. Re: [mistral][osc-lib][openstackclient] is it too early for
      orc-lib? (Renat Akhmerov)
    12. Re: [nova][infra][ci] bulk repeating a test job on a single
      review in parallel ? (Kashyap Chamarthy)
    13. [tricircle] (Luck Dog)
    14. Re: New Python35 Jobs coming (Victor Stinner)
    15. Re: Openstack Mitaka Neutron LBaaS Question (Elena Ezhova)
    16. Re: [kuryr] kuryr-libnetwork split (Antoni Segura Puimedon)
    17. Re: [neutron][upgrades] Bi-weekly upgrades work status.
      6/20/2016 (Damon Wang)
    18. Re: [kolla][ironic] My thoughts on Kolla + BiFrost
      integration (Stephen Hindle)
    19. Re: [daisycloud-core] [kolla] Kolla Mitaka
      requirementssupported by CentOS (hu.zhijiang@zte.com.cn)
    20. Re: [daisycloud-core] [kolla] Kolla Mitaka
      requirementssupported by CentOS (Gerard Braad)
    21. ??: [probably forge email???????]Re: [daisycloud-core] Kolla
      Mitaka requirementssupported by CentOS (hu.zhijiang@zte.com.cn)
    22. Re: [Openstack-operators] [nova] Fail build request if we
      can't inject files? (Daniel P. Berrange)
    23. Re: [all][Python 3.4-3.5] Async python clients (Julien Danjou)
    24. Re: [Fuel] - Nominate Maksim Malchuk to Fuel Library Core
      (Sergii Golovatiuk)
    25. 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@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Questions about instance actions'
update and finish
Message-ID: d53105c4-4184-a737-a27c-f8b981cabb8b@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@dague.net
sean@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 updatedat = createdat 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 updatedat 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 (createdat
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.

  1. Order the results by updatedat,createdat so that if
    updatedat
    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@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@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@linux.vnet.ibm.com
To: openstack-dev@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@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@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@dstanek.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'
object has no attribute 'headers'
Message-ID: <20160703132307.GA45453@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@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/rolesget.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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle] Error when running Devstack
Message-ID:
<
CA+NahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5+LEsyTMvNsh3g-A@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@Host$cd ~
stack@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@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 requestids:
['req-e97f6276-8e19-408b-829a-004a31256453']
lib/neutron
plugins/services/l3:createneutroninitialnetwork:203
lib/neutron
plugins/services/l3:createneutroninitialnetwork: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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Cc: "openstack@lists.openstack.org" openstack@lists.openstack.org
Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question
Message-ID:
<CA+NahOUMgiNoKAnzrZKrOgo=Eigrpv8VHaSZzPxwC=
WLtQCnEQ@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@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
serviceplugins =
router,neutron
lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

[serviceproviders]
service
provider =

LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

/etc/openstack-dashboard/local_settings.py

OPENSTACKNEUTRONNETWORK = {
'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@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@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@linux.vnet.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org,
"openstack-operators@lists.openstack.org"
openstack-operators@lists.openstack.org
Subject: [openstack-dev] [nova] Fail build request if we can't inject
files?
Message-ID: 3e959d6e-09b3-4047-ff31-c44efab981f3@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@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'
object has no attribute 'headers'
Message-ID: 1d1282b2e4d7eb4d4c701c0ed0b55551@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomaryov@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@gessau.net
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] New Python35 Jobs coming
Message-ID: 314a3c1e-7111-38ab-3545-d3cb302a4d02@gessau.net
Content-Type: text/plain; charset=utf-8

Clark Boylan cboylan@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@daviey.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla][horizon] Out of branch horizon
plugins?
Message-ID:
<
CACyjiAhWiOTvZjAKyibSC4wpHyK6c9+cNK0dzy_dFxSgX+ckAA@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 openstackdashboard/local/enabled/
cp /path/to/local/defualt/settings
openstack
dashboard/local/localsettings.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@fewbar.com
To: openstack-dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] New Python35 Jobs coming
Message-ID: 1467591512-sup-6679@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@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@gbraad.nl
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Kolla] [docker] Storage-driver and loopback
usage?
Message-ID:
<CAGrH30WswSoHyeSOSNse3kJcPwkZOdLxu=
Fd9ki7UGGu3Xw_ww@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@inodes.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [grenade] upgrades vs rootwrap
Message-ID:
<
CAPAH3fkw+MBAjHVAmS29+viS07PJXdM3RukK0fhx-gv2fyRw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Sat, 2 Jul 2016 at 01:02 Matt Riedemann mriedem@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.


Message: 14
Date: Sun, 3 Jul 2016 23:41:22 -0400
From: Steve Martinelli s.martinelli@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [keystone] spec freeze on july 8th, 2016
Message-ID:
<CAHc_MXHV+bj-c36=bDxUZ1SU=
FFy-jy2ssSnaVEHFxd3fLGFag@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [docker] Storage-driver and
loopback usage?
Message-ID:
<CAATxhGftHCoJMkX-vabJugNCK+DBom6m3qGZj051tZS=
7fHg@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@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the
world"
Message-ID:
<
CA+DTi5w-azo949HhOnp7gufu0Lsov77C1dUnHaBG_8SVneGD+g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, Jul 1, 2016 at 9:26 PM, Jesse Pretorius <
Jesse.Pretorius@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@rackspace.com and delete the
original message. Your cooperation is appreciated.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@suse.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] New Python35 Jobs coming
Message-ID: 5779F1B1.3080500@suse.com
Content-Type: text/plain; charset="windows-1252"

On 07/03/2016 09:26 PM, Henry Gessau wrote:

Clark Boylan cboylan@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] New Python35 Jobs coming
Message-ID:
<CALzSdtnL==UYr7-WS54G=
HJrFxSHwESdF-W-W6Sz8F7jKe1wfQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2016-07-04 8:18 GMT+03:00 Andreas Jaeger aj@suse.com:

On 07/03/2016 09:26 PM, Henry Gessau wrote:

Clark Boylan cboylan@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Questions about instance actions'
update and finish
Message-ID:
<CAO0b__-CoU9UDaVQEFrtL9=
L92TbZhJUwkYfs9iA7R-xVM+pwg@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@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@dague.net
sean@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 updatedat = createdat 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 updatedat 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 (createdat
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.

  1. Order the results by updatedat,createdat so that if
    updatedat
    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@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@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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@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@gmail.com > wrote:
On Thu, Jun 30, 2016 at 8:38 AM, Hardik <
hardik.parekh@nectechnologies.in hardik.parekh@nectechnologies.in>
wrote:
Regarding osc-lib we have mainly two changes.

1) Used "utils" which is moved from openstackclient.common.utils to
osclib.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@gmail.com dtroyer@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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
  1. 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@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@gmail.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]
Message-ID:
<
CAL-y67hjWJ7XrOUjLiMZGV2va5z921jxMN3YL1a-GCh+i58w@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:networktype': u'flat', u'name': u'public',
u'provider:physical
network': u'public', u'adminstateup': True}}^[[00m
^[[00;33mfrom (pid=29980) preparerequestbody
/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) makereservation
/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.innerexc
^[[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.forcereraise()
^[[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 forcereraise
^[[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/oslodb/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 createnetwork
^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
^[[01;35m^[[00m is
external =
self.ensureazsetforexternalnetwork(netdata)
^[[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
azsetforexternalnetwork
^[[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 requestids:
['req-e97f6276-8e19-408b-829a-004a31256453']
lib/neutron
plugins/services/l3:createneutroninitialnetwork:203
lib/neutron
plugins/services/l3:createneutroninitialnetwork: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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] New Python35 Jobs coming
Message-ID: dd699b65-c199-2ec5-4e4a-70236971d5d4@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Cc: "openstack@lists.openstack.org" openstack@lists.openstack.org
Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question
Message-ID:
<CAFZxAhh=S0QfS+K=
Jtgmx26TMH_goxYFEibKkBmVWLowL7FGUQ@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

which
has some troubleshooting tips.

Thanks,
Elena

On Sat, Jul 2, 2016 at 1:24 AM, zhihao wang wangzhihaocom@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
serviceplugins =
router,neutron
lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

[serviceproviders]
service
provider =

LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

/etc/openstack-dashboard/local_settings.py

OPENSTACKNEUTRONNETWORK = {
'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@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@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@midokura.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split
Message-ID:
<CAP8JW8DxfO+KMPKriHST2w-3kzRKiyKu6j=8j2En=
QqR3u4A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, Jul 1, 2016 at 7:58 PM, Doug Hellmann doug@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades
work status. 6/20/2016
Message-ID:
<
CABZYMH4S8tc3XxAQbgRsuE2YyDwo6rf5v2u7u0KF+wFtceRaWw@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@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:

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 .objcontext:
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
- getobject() switched to using _querymodel 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

  1. 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@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@llnw.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +
BiFrost integration
Message-ID:
<CANPbtNEUxPV8FYEvQCaTR5XEKp98wik2USYfF=
EugBFXL2jg@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@cisco.com
wrote:

Stephen,

Responses inline.

On 7/1/16, 11:35 AM, "Stephen Hindle" shindle@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@intel.com wrote:

-----Original Message-----
From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Monday, June 27, 2016 9:21 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@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@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@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@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@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@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@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@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@zte.com.cn
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka
requirementssupported by CentOS
Message-ID:
<
OF685C0E9F.8AD230D6-ON48257FE6.002BD37A-48257FE6.002C2309@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@fedoraproject.org
???: "OpenStack Development Mailing List (not for usage
questions)" openstack-dev@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@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@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@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@gbraad.nl
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka
requirementssupported by CentOS
Message-ID:
<
CAGrH30XrpdS2D8UvPdcSMfMdJM1ExsKysaX_f0gLa4miUyf6oQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

???: Ha?kel hguemar@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@zte.com.cn
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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@fedoraproject.org
???: "OpenStack Development Mailing List (not for usage
questions)" openstack-dev@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@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@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@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@redhat.com
To: Matt Riedemann mriedem@linux.vnet.ibm.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org,
"openstack-operators@lists.openstack.org"
openstack-operators@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [nova] Fail build
request if we can't inject files?
Message-ID: 20160704084021.GA3763@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@danjou.info
To: Denis Makogon lildee1991@gmail.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python
clients
Message-ID: m04m85bw6e.fsf@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel
Library Core
Message-ID:
<CA+HkNVup=8XN9cRU-Te7B13G5TM8LP=c7FLWskqte=
fyOBQMBg@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@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@mirantis.com>
wrote:

+1

On Tue, Jun 28, 2016 at 1:12 PM, Kyrylo Galanov kgalanov@mirantis.com
wrote:

+1

On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn <
mmosesohn@mirantis.com> wrote:

+1. Maksim is an excellent reviewer.

On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz aschultz@mirantis.com
wrote:

+1

On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya <
bdobrelia@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@mirantis.com sgolovatiuk@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@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@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@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@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@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@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@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@gmail.com
To: Denis Makogon lildee1991@gmail.com, "OpenStack Development
Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python
clients
Message-ID:
<CALzSdtnQtzUNCjP+6u4GO=qNesD0q+KZPDZ7=
QmSGcrG7oqr9A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2016-07-04 12:16 GMT+03:00 Julien Danjou julien@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 5, 2016 in openstack-dev by Luck_Dog (340 points)   1 1
retagged Jan 26, 2017 by admin

1 Response

0 votes
responded Jul 5, 2016 by Shinobu_Kinjo (5,960 points)   1 2 2
...