[openstack-dev] [kolla] Getting test-requirements.txt into project images

[Joshua Harlow]

Hi kolla folks,

I've got the following going (via jenkins):

"Cloning (and stashing) required repositories"
 |
 |
 v
"Extracting project specific patches (and skippable tests) "
 |
 |
 v
...
"Building heat images using kolla"
 |
 |
 v
"(Unit) testing heat image"

Now the neat part is that the testing happens post-image being built (so 
that I can know that the patches we applied don't badly affect all the 
unit tests for the project *before* the image is pushed to our artifactory).


This all seems to go ok except for one small snag, and that snag is 
getting the projects (unit)test requirements into the image.


I've had to do the following (which seems sorta not so good):

{% block ${project}_base_footer %}
ADD plugins-archive /
RUN /var/lib/kolla/venv/bin/pip --no-cache-dir \
install --upgrade -c requirements/upper-constraints.txt \
-r ${project}/test-requirements.txt \
-r ${project}/requirements.txt
RUN /var/lib/kolla/venv/bin/pip --no-cache-dir \
install os-testr -c requirements/upper-constraints.txt
{% endblock %}

Where in the above ${project} is a variable that changes depending on 
which project we are building.


Is there any better way to request that `test-requirements.txt` gets 
installed?


Thoughts?

-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-odl] Neutron with OpenDaylight Boron controller

[Isaku Yamahata]

Hello Elena.

Added related opendaylight mailing lists to cc.
Probably you'll get more reply by sending a mail to OpenDaylight specific
mailing list.

thanks,


On Wed, Dec 07, 2016 at 04:20:37PM +0400,
Elena Ezhova  wrote:

> Hi folks,
> 
> We are trying to deploy Neutron with OpenDaylight Boron-0.5.0 controller
> using DevStack (master version) on Ubuntu 14.04 and there is a number of
> issues we face.
> 
> First, we tried to deploy OpenDaylight with odl-ovsdb-openstack feature
> using the following local.conf [0]. In this case VMs successfully got IP
> addresses and L2 connectivity was working, but there was no L3 connectivity
> meaning we couldn't ping router IP from qdhcp namespace and VMs in
> different subnets couldn't reach each other.
> We've also tried to deploy OpenDaylight odl-ovsdb-openstack with Neutron L3
> agent by enabling q-l3 and setting ODL_L3=False in local.conf, but in this
> case stack.sh failed due to br-int not having been created.
> 
> After that, we were given an advice on opendaylight irc channel to use
> odl-netvirt-openstack feature instead as odl-ovsdb-openstack is kind of
> deprecated.
> When deploying Neutron+ODL with this feature we were referencing the
> NetVirt demo from the latest ODL summit [1] as well as networking-odl
> DevStack guide [2] and our local.conf was looking the following way [3].
> As a result, though br-int is created and when a subnet or a VM are created
> corresponding tap interfaces are added, there is no L2 and L3 connectivity
> and there are a lot of error in karaf logs:
> 
>- Errors on start: http://paste.openstack.org/show/591432/
>- Logs during Neutron subnet create:
>http://paste.openstack.org/show/591437/
>- OVS ports and flows after a Neutron network with a subnet were
>created: http://paste.openstack.org/show/591642/ .
>Here it seems that not all flows had been created, for example there is
>a flow in table 51 that sends traffic to table 52 which is missing.
>- There are also tons of traces identical to ones in bug [4] which
>should have been fixed in Beryllium release.
> 
> Has someone successfully deployed operational Neutron+OpenDaylight with
> NetVirt or ovsdb feature recently? If so, we would really appreciate an
> example of local.conf that was used as well as any clues that point out
> what we can be missing.
> 
> Thanks,
> Elena
> 
> [0] http://paste.openstack.org/show/591645/
> https://docs.google.com/presentation/d/1VLzRIOEptSOY1b0w4PezRIQ0gF5vx7GyLKECWXRV5mE/edit#slide=id.g17efbe8461_0_146
> [2]
> https://github.com/openstack/networking-odl/blob/master/devstack/README.rst
> [3] http://paste.openstack.org/show/591641/
> [4] https://bugs.opendaylight.org/show_bug.cgi?id=5275

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Isaku Yamahata 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron-lbaas] [octavia]vip failed to be plugged in to the amphorae vm

[Kosnik, Lubosz]

Plugging VIP worked without any problems.
Log is telling that you have very restrictive timeout configuration. 7 retries 
is very low configuration. Please reconfigure this to much bigger value.

Regards,
Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

On Dec 9, 2016, at 3:46 PM, Wanjing Xu (waxu) 
> wrote:

I have stable/metaka Octavia which has been running OK until today, whenever I 
created loadbalancer, the amphorae vm is created with mgmt nic. But look like 
vip plugin failed.  I can ping to amphorae mgmt. NIC from controller(where 
Octavia process is running), but look like some rest api call  into amphorae to 
plug in vip failed :

Ping works:

[localadmin@dmz-eth2-ucs1]logs> ping 192.168.0.7
PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_seq=1 ttl=64 time=1.11 ms
64 bytes from 192.168.0.7: icmp_seq=2 ttl=64 time=0.461 ms
^C


o-cw.log:

2016-12-09 11:03:54.468 31408 DEBUG 
octavia.controller.worker.tasks.network_tasks [-] Retrieving network details 
for amphora ae80ae54-395f-4fad-b0de-39f17dd9b19e execute 
/opt/stack/octavia/octavia/controller/worker/tasks/network_tasks.py:380
2016-12-09 11:03:55.441 31408 DEBUG octavia.controller.worker.controller_worker 
[-] Task 
'octavia.controller.worker.tasks.network_tasks.GetAmphoraeNetworkConfigs' 
(76823522-b504-4d6a-8ba7-c56015cb39a9) transitioned into state 'SUCCESS' from 
state 'RUNNING' with result '{u'ae80ae54-395f-4fad-b0de-39f17dd9b19e': 
}' 
_task_receiver 
/usr/local/lib/python2.7/dist-packages/taskflow/listeners/logging.py:178
2016-12-09 11:03:55.444 31408 DEBUG octavia.controller.worker.controller_worker 
[-] Task 
'octavia.controller.worker.tasks.amphora_driver_tasks.AmphoraPostVIPPlug' 
(3b798537-3f20-46a3-abe2-a2c24c569cd9) transitioned into state 'RUNNING' from 
state 'PENDING' _task_receiver 
/usr/local/lib/python2.7/dist-packages/taskflow/listeners/logging.py:189
2016-12-09 11:03:55.446 31408 DEBUG 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url 
plug/vip/100.100.100.9 request 
/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:218
2016-12-09 11:03:55.446 31408 DEBUG 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url 
https://192.168.0.7:9443/0.5/plug/vip/100.100.100.9 request 
/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:221
2016-12-09 11:03:55.452 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:56.458 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:57.462 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:58.466 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:59.470 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:04:00.474 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:04:02.487 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
……
ransitioned into state 'REVERTED' from state 'REVERTING' with result 'None'
2016-12-09 11:29:10.509 31408 WARNING 
octavia.controller.worker.controller_worker [-] Flow 
'post-amphora-association-octavia-post-loadbalancer-amp_association-subflow' 
(f7b0d080-830a-4d6a-bb85-919b6461252f) transitioned into state 'REVERTED' from 
state 'RUNNING'
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher [-] Exception 
during message handling: contacting the amphora timed out
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
138, in _dispatch_and_reply
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher 
incoming.message))
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
185, in _dispatch
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher return 
self._do_dispatch(endpoint, method, ctxt, args)
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
127, in _do_dispatch
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/opt/stack/octavia/octavia/controller/queue/endpoint.py", line 45, in 
create_load_balancer
2016-12-09 

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Michał Jastrzębski]

Thank you for getting this done Jeffrey:) Congratulations zhubingbing!

On 7 December 2016 at 00:34, Jeffrey Zhang  wrote:
> zhubingbing,
>
> Congratulations, the vote passed with ( 10 votes, without a veto ).
>
> I've added you to the appropriate group in Gerrit.  I'll give you
> some training on the policies for core reviewers.
>
> PS: Since Michal is out on vacation recently, I will take the PTL
> duty for a while.
>
> On Fri, Dec 2, 2016 at 11:05 AM, Swapnil Kulkarni 
> wrote:
>>
>> On Tue, Nov 29, 2016 at 9:51 PM, Michał Jastrzębski 
>> wrote:
>> > Hello team!
>> >
>> > I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
>> > core teams. He did great job reviewing code during last couple of
>> > months.
>> >
>> > Consider this proposal +1 from me, voting will be open for 1 week
>> > (until Dec 6) or if we get unanimous agreement (or veto) before.
>> >
>> > Regards,
>> > Michal
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> +1
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Magnum_driver

[Ruben]

Hi Tim,
sorry for the late, but I've had a busy week.
Anyway, I've tried to add the magnum_driver to review into a single commit.
I don't know if I have been able..

Ruben

- Messaggio originale -
Da: "Tim Hinrichs" 
A: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Inviato: Mercoledì, 30 novembre 2016 22:04:32
Oggetto: Re: [Congress] Magnum_driver

Hi Ruben,

What you're doing is correct.  The downside is that it creates a new commit
for every change you make, and all of those commits show up on gerrit.  In
OpenStack (and other projects I've seen that use Gerrit for code reviews)
you squash those commits into 1 change so that it's easier for reviewers to
see the change as a whole.  (Projects that use Github for code reviews do
more like what you're doing now).  To see your

Here's a blog showing you what to do...
https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

You can probably do

$ git rebase -i

and then follow the instructions in the blog that say you replace the
'pick' for all the commits after the first with 'squash' (or 's' for
short).  So something like the following.

pick f392171 Added new feature X squash ba9dd9a Added new elements to page
design squash df71a27 Updated CSS for new elements

After that, you should be able to do ...

$ git review

Tim

On Wed, Nov 30, 2016 at 5:23 AM Ruben 
wrote:

> Hi Tim,
> what should I do to squash all the commits into a single one?
>
> To add the code to review I made:
>
> git add 
> git commit
> git review
>
> Isn't it correct?
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Mercoledì, 30 novembre 2016 2:34:22
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> I left a comment on one of the changes; after you take care of that I'll
> take a closer look at the code.  Let me know if you have questions.
>
> Tim
>
> On Tue, Nov 29, 2016 at 4:06 AM Ruben 
> wrote:
>
> > Hi Tim,
> > I've added the code of magnum_driver and its unit test to review.
> > It seems everything works.
> >
> > Ruben
> >
> > - Original Message -
> > From: "Tim Hinrichs" 
> > To: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Sent: Saturday, November 26, 2016 12:48:12 AM
> > Subject: Re: [Congress] Magnum_driver
> >
> > Definitely push that code up into Gerrit so we can all take a look.  Data
> > like pods and containers is probably the most valuable data from Magnum,
> so
> > I'd definitely recommend adding that.  But push the code you have to
> Gerrit
> > first.  (As long as you leave the ChangeId the same each time you push to
> > Gerrit, Gerrit will keep all of the versions you pushed organized
> together,
> > yet keep the versions separate.)
> >
> > Tim
> >
> > On Fri, Nov 25, 2016 at 3:06 PM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > You are great. It works! Thanks a lot!
> > > I've also solved the problem with py27. The unit test seems to work.
> > > The only thing that seems not to work is populate the 'clusters_links'
> > and
> > > 'cluster_templates_links' tables: they are empty.
> > > Also, the 'labels' table is empty.
> > > I've no errors anyway.
> > > Are these problems according to you?
> > >
> > > Should I to try to add the translation of pods, containers and
> services?
> > >
> > > I've add the code to review.
> > >
> > > Ruben
> > > - Original Message -
> > > From: "Tim Hinrichs" 
> > > To: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Sent: Friday, November 25, 2016 10:36:29 PM
> > > Subject: Re: [Congress] Magnum_driver
> > >
> > > Hi Ruben,
> > >
> > > Glad you got that worked out.  Once in a while I end up deleting my
> .tox
> > > dir because it gets out of date.  I guess that's what the --recreate
> > option
> > > to tox does.  So I learned something.  :)
> > >
> > > The new error message looks to be saying that an object of type
> 'Cluster'
> > > cannot be iterated.  Congress's _translate_clusters method assumes that
> > > what you give it is basically JSON (arrays, dictionaries, numbers,
> > strings,
> > > bools).   In this case Congress is trying to iterate over the keys of a
> > > dictionary but is getting a 'Cluster' Python object instead.  What's
> > > happening is that when you do the cluster.list() (or whatever it's
> > called)
> > > on the magnum-python you're getting back a list of Cluster Python
> objects
> > > instead of a list of dictionaries.
> > >
> > > To fix the problem, 

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

[Clark Boylan]

On Fri, Dec 9, 2016, at 01:42 PM, Ihar Hrachyshka wrote:
> Ihar Hrachyshka  wrote:
> 
> > Jeremy Stanley  wrote:
> >
> >> On 2016-10-04 18:22:10 +0200 (+0200), Ihar Hrachyshka wrote:
> >> [...]
> >>> When I execute 'bindep test’ locally, I get the following error on  
> >>> centos7.2
> >>> which is expected:
> >>>
> >>> Bad versions of installed packages:
> >>> sqlite version 3.7.17-8.el7 does not match >=3.8
> >>>
> >>> I would think that this output is passed to apt-get in the gate. But  
> >>> then I
> >>> see the following failure in gate:
> >>>
> >>> http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699
> >> [...]
> >>
> >> We hashed this out just now in #openstack-infra, but the quick
> >> summary is that version specifiers with bindep are sort of
> >> experimental. They were added as part of its initial design but the
> >> first implementation was dpkg-only and made some assumptions about
> >> how distros track available vs installed package versions that
> >> couldn't easily be extended to other platforms. As a result, when we
> >> started adding rpm (and then later emerge) support, we pretty much
> >> just punted on version handling until someone actually turned up who
> >> needed it and was willing to do the work to add it in a useful
> >> cross-platform manner. For now at least, version specifiers have
> >> poor coverage in bindep's unit tests and no coverage in its
> >> functional tests and have probably bit-rotted on us.
> >>
> >> It's on me that I forgot we actually mention version constraints in
> >> the bindep documentation, with no indication that they aren't a
> >> first-class feature at the moment. Anyway, it sounds like you may
> >> have time and interest to help us get this supported properly (at
> >> least for rpm-based platforms), so I'm thrilled and looking forward
> >> to working with you toward that goal. Thanks again!
> >> -- 
> >> Jeremy Stanley
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > For reader’s sake, the patch to support versions for brief mode of the  
> > tool is: https://review.openstack.org/#/c/381979/
> 
> I hate to be PITA but the patch did not get any review attention for two  
> months+, even with frequent irc pings of relevant folks. I wanted to
> reuse  
> versioned dependencies for Neutron as a self-documenting contract with  
> platforms and distributions; but without this feature completed, I can’t  
> really move forward with it, and if nothing changes, we may probably end
> up  
> crafting some custom tracking file for basically the same matter.
> 
> I still hope we can get this in, and then reuse bindep.txt for minimal  
> runtime dependencies version tracking for interested projects. The patch
> is  
> small, it should not take much time for a seasoned reviewer...

How do you intend to have this work on CentOS 7 if it requires a newer
version of rpm than is available on CentOS 7? There are comments about
maybe warning the user at the very least.

Also, I think there is a bug in the output for more complex version
requirements. Comments left on change.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Requirements] [Horizon] upper-constraints shenanigans and development milestones

[Richard Jones]

Hi folks,

We in Horizon land are looking to update to a new version of one of
our dependencies, Angular Bootstrap version 2.2.0. We do this through
xstatic packaging, so the release we'll be making is actually
xstatic-angular-bootstrap 2.2.0.0

This release is backward incompatible and breaks Horizon in many ways.
We already have a compatibility patch in review to get us up to speed
in Ocata, but prior versions of Horizon would break without
upper-constraints protections. We've recently pushed through several
changes to stable Mitaka to get those protections in place - Newton
was already protected.

The problem is that we'll have two Ocata milestone releases out when
2.2.0.0 is released, and those will break because we currently pull in
*master* upper-constraints for the milestone releases, rather than a
stable/ocata branch of upper-constraints - there is no stable/ocata
branch of upper-constraints yet.

Has the idea of branching at development milestones been raised previously?


Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron-lbaas] [octavia]vip failed to be plugged in to the amphorae vm

[Wanjing Xu (waxu)]

I have stable/metaka Octavia which has been running OK until today, whenever I 
created loadbalancer, the amphorae vm is created with mgmt nic. But look like 
vip plugin failed.  I can ping to amphorae mgmt. NIC from controller(where 
Octavia process is running), but look like some rest api call  into amphorae to 
plug in vip failed :

Ping works:

[localadmin@dmz-eth2-ucs1]logs> ping 192.168.0.7
PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_seq=1 ttl=64 time=1.11 ms
64 bytes from 192.168.0.7: icmp_seq=2 ttl=64 time=0.461 ms
^C


o-cw.log:

2016-12-09 11:03:54.468 31408 DEBUG 
octavia.controller.worker.tasks.network_tasks [-] Retrieving network details 
for amphora ae80ae54-395f-4fad-b0de-39f17dd9b19e execute 
/opt/stack/octavia/octavia/controller/worker/tasks/network_tasks.py:380
2016-12-09 11:03:55.441 31408 DEBUG octavia.controller.worker.controller_worker 
[-] Task 
'octavia.controller.worker.tasks.network_tasks.GetAmphoraeNetworkConfigs' 
(76823522-b504-4d6a-8ba7-c56015cb39a9) transitioned into state 'SUCCESS' from 
state 'RUNNING' with result '{u'ae80ae54-395f-4fad-b0de-39f17dd9b19e': 
}' 
_task_receiver 
/usr/local/lib/python2.7/dist-packages/taskflow/listeners/logging.py:178
2016-12-09 11:03:55.444 31408 DEBUG octavia.controller.worker.controller_worker 
[-] Task 
'octavia.controller.worker.tasks.amphora_driver_tasks.AmphoraPostVIPPlug' 
(3b798537-3f20-46a3-abe2-a2c24c569cd9) transitioned into state 'RUNNING' from 
state 'PENDING' _task_receiver 
/usr/local/lib/python2.7/dist-packages/taskflow/listeners/logging.py:189
2016-12-09 11:03:55.446 31408 DEBUG 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url 
plug/vip/100.100.100.9 request 
/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:218
2016-12-09 11:03:55.446 31408 DEBUG 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url 
https://192.168.0.7:9443/0.5/plug/vip/100.100.100.9 request 
/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:221
2016-12-09 11:03:55.452 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:56.458 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:57.462 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:58.466 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:03:59.470 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:04:00.474 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
2016-12-09 11:04:02.487 31408 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to 
instance. Retrying.
……
ransitioned into state 'REVERTED' from state 'REVERTING' with result 'None'
2016-12-09 11:29:10.509 31408 WARNING 
octavia.controller.worker.controller_worker [-] Flow 
'post-amphora-association-octavia-post-loadbalancer-amp_association-subflow' 
(f7b0d080-830a-4d6a-bb85-919b6461252f) transitioned into state 'REVERTED' from 
state 'RUNNING'
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher [-] Exception 
during message handling: contacting the amphora timed out
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
138, in _dispatch_and_reply
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher 
incoming.message))
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
185, in _dispatch
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher return 
self._do_dispatch(endpoint, method, ctxt, args)
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
127, in _do_dispatch
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/opt/stack/octavia/octavia/controller/queue/endpoint.py", line 45, in 
create_load_balancer
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher 
self.worker.create_load_balancer(load_balancer_id)
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher   File 
"/opt/stack/octavia/octavia/controller/worker/controller_worker.py", line 322, 
in create_load_balancer
2016-12-09 11:29:10.509 31408 ERROR oslo_messaging.rpc.dispatcher 
post_lb_amp_assoc.run()
2016-12-09 

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

[Ihar Hrachyshka]

Ihar Hrachyshka  wrote:


Jeremy Stanley  wrote:


On 2016-10-04 18:22:10 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
When I execute 'bindep test’ locally, I get the following error on  
centos7.2

which is expected:

Bad versions of installed packages:
sqlite version 3.7.17-8.el7 does not match >=3.8

I would think that this output is passed to apt-get in the gate. But  
then I

see the following failure in gate:

http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699

[...]

We hashed this out just now in #openstack-infra, but the quick
summary is that version specifiers with bindep are sort of
experimental. They were added as part of its initial design but the
first implementation was dpkg-only and made some assumptions about
how distros track available vs installed package versions that
couldn't easily be extended to other platforms. As a result, when we
started adding rpm (and then later emerge) support, we pretty much
just punted on version handling until someone actually turned up who
needed it and was willing to do the work to add it in a useful
cross-platform manner. For now at least, version specifiers have
poor coverage in bindep's unit tests and no coverage in its
functional tests and have probably bit-rotted on us.

It's on me that I forgot we actually mention version constraints in
the bindep documentation, with no indication that they aren't a
first-class feature at the moment. Anyway, it sounds like you may
have time and interest to help us get this supported properly (at
least for rpm-based platforms), so I'm thrilled and looking forward
to working with you toward that goal. Thanks again!
--
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


For reader’s sake, the patch to support versions for brief mode of the  
tool is: https://review.openstack.org/#/c/381979/


I hate to be PITA but the patch did not get any review attention for two  
months+, even with frequent irc pings of relevant folks. I wanted to reuse  
versioned dependencies for Neutron as a self-documenting contract with  
platforms and distributions; but without this feature completed, I can’t  
really move forward with it, and if nothing changes, we may probably end up  
crafting some custom tracking file for basically the same matter.


I still hope we can get this in, and then reuse bindep.txt for minimal  
runtime dependencies version tracking for interested projects. The patch is  
small, it should not take much time for a seasoned reviewer...


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [Openstack-operators] How to expose the compute node local disks to instances

[Belmiro Moreira]

Hi Sean,
thanks for the suggestions.

On Thu, 8 Dec 2016 at 23:10, Sean McGinnis  wrote:

> Hi Belmiro,
>
> In Cinder there is the "raw disk device" driver that has been used by some
> for Hadoop and similar applications. That may be something to look at, but
> with a big warning.
>
> That being that it is deprecated in the Ocata release and will be removed
> in Pike.
>
> The reason it is going to be removed has a couple reasons though. One big
> one is that it is unable to meet the "minimum feature set" that we require
> for a Cinder driver. There are just too many restrictions on what can be
> done when you're using raw disk.
>
> The other reason was that after running a set of tests, it we really didn't
> see that much of a difference in uing the raw device driver vs. configuring
> the LVM driver appropriately. I don't have the full details of those tests
> handy at the moment, but I'm sure we can track down some specifics if
> needed.
>
> So I would recommend connecting your JBODs to some compute hosts and using
> that disk space to back LVM, then configure Cinder with the LVM driver to
> use that pool of space to present volumes to your compute instances.
>
> Thanks,
> Sean
>
> On Thu, Dec 08, 2016 at 07:46:35PM +0100, Belmiro Moreira wrote:
> > Hi,
> >
> > we have a set of disk servers (JBOD) that we would like to integrate into
> > our cloud to run   applications like Hadoop and Spark.
> >
> > Using file disks for storage and a huge "/var/lib/nova" is not an option
> > for these use cases so we would like to expose the local drives directly
> to
> > the VMs as ephemeral disks.
> >
> >
> >
> > Is there already something in Nova that allows this?
> >
> >
> >
> > thanks,
> >
> > Belmiro
> >
> > CERN
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Steve Martinelli]

At the last TC meeting [1] we discussed this topic and the various options
that were presented, here's a quick recap:

Options that will be removed, the patches for these options will be
abandoned:
  - Red (option 6), it had the least support
  - Hard black (option 1) in favor of soft black (option 2)
  - Hard white (option 3) in favor of soft white (option 4)

Remaining Options:
  - Soft black (option 2): default option, had no negative feedback,
represents the current status quo
  - Soft white (option 4): had some positive feedback, folks liked it's
simple solution
  - Grey (option 5): had the most positive feedback, but also the least
amount of detail

We'll continue to iterate on the remaining three options.

 - steve

[1]
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt


On Mon, Nov 28, 2016 at 1:33 PM, Doug Hellmann 
wrote:

> The OpenStack community wants to encourage collaboration by emphasizing
> contributions to projects that abstract differences between
> vendor-specific products, while still empowering vendors to integrate
> their products with OpenStack through drivers that can be consumed
> by the abstraction layers.
>
> Some teams for projects that use drivers may not want to manage
> some or all of the drivers that can be consumed by their project
> because they have little insight into testing or debugging the code,
> or do not have the resources needed to manage centrally a large
> number of separate drivers. Vendors are of course free to produce
> drivers to integrate with OpenStack completely outside of the
> community, but because we value having the drivers as well as the
> more general support of vendor companies, we want to encourage a
> higher level of engagement by welcoming vendor-specific teams to
> be a part of our community governance.
>
> Our Requirements for New Projects list [0] includes a statement
> about establishing a "level and open collaboration playing field"
>
>   The project shall provide a level and open collaboration playing
>   field for all contributors. The project shall not benefit a single
>   vendor, or a single vendors product offerings; nor advantage
>   contributors from a single vendor organization due to access to
>   source code, hardware, resources or other proprietary technology
>   available only to those contributors.
>
> This requirement makes it difficult to support having teams focused
> on producing a deliverable that primarily benefits a single vendor.
> So, we have some tension between wanting to collaborate and have a
> level playing field, while wanting to control the amount of driver
> code that projects have to manage.
>
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"
>
> To that end, I've been working with fungi and ttx to identify all
> of our options. We've come up with a "spectrum", which I will try
> to summarize here but please read the associated governance patches
> for the full details. (Please note that although we've split up the
> work of writing the patches, each author may not necessarily support
> all of the patches he has submitted.)
>
> 1. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it effectively precludes official status
>for teams which only develop drivers for proprietary systems
>(hard black) [2]
>
>This would have the immediate effect of denying the Cisco team's
>request, as well as precluding future requests from similar teams.
>
> 2. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it does not necessarily preclude official
>status for teams which only develop drivers for proprietary
>systems (soft black) [3]
>
>This would allow driver-specific teams for systems as long as
>those drivers can be developed without access to proprietary
>information. The TC would have to consider how this applies to
>each team's request as it is evaluated.
>
> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
>
>This would completely remove the problematic wording from the
>governance documents (eliminate the restriction on benefiting a
>single company and consider access to specific information for
>some contributors to not be a problem).
>
> 4. A resolution and policy change loosening the "level playing field"
>requirement (soft white) [5]
>
>This would add an exception to the existing wording in the
>governance documents to exempt teams working only on drivers.
>They would still be subject to all of our other policies, unless
>similar exceptions are included.
>
> 5. Consider driver teams to be a completely different animal, 

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

[John Villalovos]

On Wed, Dec 7, 2016 at 5:29 AM, Thierry Carrez 
wrote:

> So how about:
> - we enable an #openstack-meeting-5 to instantly relieve scheduling
> pressure
>

Any reason it isn't #openstack-meeting-2 ?

The -2 channel is owned by openstackinfra.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error with gerrit, devstack

[Raildo Mascena]

Hi Annapoornima,

You probably had some issue related with your key or some lib/package
during the installation.

I suggest follow the Developer's Guide here:
http://docs.openstack.org/infra/manual/developers.html and make sure that
everything is ok.

Cheers,

Raildo

On Fri, Dec 9, 2016 at 2:18 PM Clark Boylan  wrote:

> On Fri, Dec 9, 2016, at 09:11 AM, Annapoornima Koppad wrote:
> > Dear All,
> >
> > I am facing this problem with Devstack Gerrit process. Can someone help?
> >
> > Here is my problem. I had an old machine on which I installed git, git
> > cloned Devstack and contributed some patches to Openstack. My old machine
> > was as useless as it could get. So, I bought a new Dell Inspiron machine
> > and installed Ubuntu 16.04. I git cloned Devstack again, and installed
> > git.
> > I uploaded the SSH keys to https://review.openstack.org/#/settings/. I
> > tried to hook up Gerrit with git so that I could start working on patches
> > as well. When I did the following:
> >
> > git review -s
> >
> > I ran into the following problem.
> >
> > Problem running 'git remote update gerrit'
> > Fetching gerrit
> > fatal: unable to access
> > '
> https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git/
> ':
> > gnutls_handshake() failed: An unexpected TLS packet was received.
> > error: Could not fetch gerrit
> > Problems encountered installing commit-msg hook
> > The following command failed with exit code 255
> > "GET
> > https://annakop...@review.openstack.org:29418/tools/hooks/commit-msg;
> > ---
> > ("bad handshake: Error([('SSL routines', 'SSL23_GET_SERVER_HELLO',
> > 'unknown protocol')],)",)
> >
> > My git config --list looks like this.
> >
> > user.name=Annapoornima Koppad
> > user.email=annakop...@gmail.com
> > gitreview.username=annakoppad
> > core.repositoryformatversion=0
> > core.filemode=true
> > core.bare=false
> > core.logallrefupdates=true
> > remote.origin.url=https://git.openstack.org/openstack-dev/devstack
> > remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
> > branch.master.remote=origin
> > branch.master.merge=refs/heads/master
> > remote.gerrit.url=
> https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git
>
> Port 29418 is an ssh port, not an https port. You should run https on
> the default port, 443. Alternately use ssh:// instead of https://.
>
> > remote.gerrit.fetch=+refs/heads/*:refs/remotes/gerrit/*
> > y local.conf looks like this.
> > [[local|localrc]]
> > ADMIN_PASSWORD=
> > DATABASE_PASSWORD=
> > RABBIT_PASSWORD=
> > SERVICE_PASSWORD=
> > GIT_BASE=${GIT_BASE:-https://git.openstack.org}
> > I restarted the machine if the changes could start again. That did not
> > work.
> >
> > What is that I am missing?
>
> I think if you get the connection protocol and ports to line up as above
> that should make git review happy.
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error with gerrit, devstack

[Clark Boylan]

On Fri, Dec 9, 2016, at 09:11 AM, Annapoornima Koppad wrote:
> Dear All,
> 
> I am facing this problem with Devstack Gerrit process. Can someone help?
> 
> Here is my problem. I had an old machine on which I installed git, git
> cloned Devstack and contributed some patches to Openstack. My old machine
> was as useless as it could get. So, I bought a new Dell Inspiron machine
> and installed Ubuntu 16.04. I git cloned Devstack again, and installed
> git.
> I uploaded the SSH keys to https://review.openstack.org/#/settings/. I
> tried to hook up Gerrit with git so that I could start working on patches
> as well. When I did the following:
> 
> git review -s
> 
> I ran into the following problem.
> 
> Problem running 'git remote update gerrit'
> Fetching gerrit
> fatal: unable to access
> 'https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git/':
> gnutls_handshake() failed: An unexpected TLS packet was received.
> error: Could not fetch gerrit
> Problems encountered installing commit-msg hook
> The following command failed with exit code 255
> "GET
> https://annakop...@review.openstack.org:29418/tools/hooks/commit-msg;
> ---
> ("bad handshake: Error([('SSL routines', 'SSL23_GET_SERVER_HELLO',
> 'unknown protocol')],)",)
> 
> My git config --list looks like this.
> 
> user.name=Annapoornima Koppad
> user.email=annakop...@gmail.com
> gitreview.username=annakoppad
> core.repositoryformatversion=0
> core.filemode=true
> core.bare=false
> core.logallrefupdates=true
> remote.origin.url=https://git.openstack.org/openstack-dev/devstack
> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
> branch.master.remote=origin
> branch.master.merge=refs/heads/master
> remote.gerrit.url=https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git

Port 29418 is an ssh port, not an https port. You should run https on
the default port, 443. Alternately use ssh:// instead of https://.

> remote.gerrit.fetch=+refs/heads/*:refs/remotes/gerrit/*
> y local.conf looks like this.
> [[local|localrc]]
> ADMIN_PASSWORD=
> DATABASE_PASSWORD=
> RABBIT_PASSWORD=
> SERVICE_PASSWORD=
> GIT_BASE=${GIT_BASE:-https://git.openstack.org}
> I restarted the machine if the changes could start again. That did not
> work.
> 
> What is that I am missing?

I think if you get the connection protocol and ports to line up as above
that should make git review happy.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Error with gerrit, devstack

[Annapoornima Koppad]

Dear All,

I am facing this problem with Devstack Gerrit process. Can someone help?

Here is my problem. I had an old machine on which I installed git, git
cloned Devstack and contributed some patches to Openstack. My old machine
was as useless as it could get. So, I bought a new Dell Inspiron machine
and installed Ubuntu 16.04. I git cloned Devstack again, and installed git.
I uploaded the SSH keys to https://review.openstack.org/#/settings/. I
tried to hook up Gerrit with git so that I could start working on patches
as well. When I did the following:

git review -s

I ran into the following problem.

Problem running 'git remote update gerrit'
Fetching gerrit
fatal: unable to access
'https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git/':
gnutls_handshake() failed: An unexpected TLS packet was received.
error: Could not fetch gerrit
Problems encountered installing commit-msg hook
The following command failed with exit code 255
"GET https://annakop...@review.openstack.org:29418/tools/hooks/commit-msg;
---
("bad handshake: Error([('SSL routines', 'SSL23_GET_SERVER_HELLO',
'unknown protocol')],)",)

My git config --list looks like this.

user.name=Annapoornima Koppad
user.email=annakop...@gmail.com
gitreview.username=annakoppad
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://git.openstack.org/openstack-dev/devstack
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
remote.gerrit.url=https://annakop...@review.openstack.org:29418/openstack-dev/devstack.git
remote.gerrit.fetch=+refs/heads/*:refs/remotes/gerrit/*
y local.conf looks like this.
[[local|localrc]]
ADMIN_PASSWORD=
DATABASE_PASSWORD=
RABBIT_PASSWORD=
SERVICE_PASSWORD=
GIT_BASE=${GIT_BASE:-https://git.openstack.org}
I restarted the machine if the changes could start again. That did not work.

What is that I am missing?

Thanks in advance.

Annapoornima
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs][badges][all] Docs gate broken for projects that include README.rst in docs

[Flavio Percoco]

Greetings,

Some docs jobs seem to be broken by the latest (or not?) docutils release. The
breakage seems to be related to the latest addition of the bages patch. The docs
generation doesn't like to have remote images. It used to be a warning but it
seems to have turned into an error now. While this is reported and fixed
upstream, we can workaround the issue by tagging the image as remote.

An example of this fix can be found here: 
https://review.openstack.org/#/q/topic:readme-badge-fix

Note that this is mostly relevant for projects that include the readme files in
their documentation. If your project doesn't do it, you can ignore this email.
That said, I'd recommend all projects to do it.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Move redis out of Pacemaker

[Pradeep Kilambi]

Hey Folks:

I would like to get some thoughts on $Subject. This came up when i was
discussing the standalone roles for telemetry. Currently when we deploy
redis in tripleo, its a pacemaker managed service. So if we were to deploy
telemetry services on a dedicated node we could. But redis will have to be
on a another node? (assuming we dont want to pull in pacemaker on to
telemetry nodes).

With most services moved out of pacemaker in Newton, I think its time to
move redis as well? Are there any constraints in moving redis to be managed
by systemd? Looking at how we do it, It should be easily movable to
systemd? Can we consider doing this for Ocata?

Thoughts?

~ Prad
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] placement/resource providers update 5

[Sylvain Bauza]

Le 09/12/2016 15:50, Chris Dent a écrit :
> 
> A shorter resource provider placement update this week. In part this
> is because some of the things to think about from last week[0] got
> resolved. What's below is essentially a collection of pending work
> related to resource providers and the placement API that needs review
> and/or discussion.
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108395.html
> 
> 
> # Pending Planned Work
> 
> ## Update Client Side to Consider Aggregates
> 
> After having this in the things to think about section last week,
> Jay's posted the start of the resource tracker work[1] which attends
> to aggregates. Above that are some placement API changes for getting a
> list of resource providers that are members of any of the provided
> aggregates.
> 
> [1] https://review.openstack.org/#/c/407309/
> 
> ## Update Scheduler to Request Limited Resource Providers
> 
> The debate on GET v POST and which URL to use for filtering resource
> providers resolved and the implementation looks good[2]. Once that's
> in we can start work on adjust the scheduler, keeping in mind what I
> quoted from Jay last week:
> 
>we will only return resource providers to the scheduler that
>are compute nodes in Ocata. the resource providers that the
>placement service returns will either have the resources
>requested or will be associated with aggregates that have
>providers that match the requested resources.
> 
> [2] https://review.openstack.org/#/c/392569/
> 

Given that now we have an agreement, I'll provide the scheduler client
change by the next week.

-Sylvain


> ## Docs
> 
> I've started a placement_dev.rst[3] (miles to go yet) and will start
> on the api-ref soon after that. placement_dev (and its cousin
> placement.rst) need some input on what people would like to see in
> those files.
> 
> [3] https://review.openstack.org/#/c/408313/
> 
> ## Custom Resource Classes
> 
> This is moving along with some of the stack of code[4] having merged.
> There was some discussion in IRC worth mentioning:
> 
> * There's still an unresolved question on how we are going to express
>   certain custom resource class scenarios in build requests,
>   especially from the ironic standpoint. The consensus at this point
>   is: a) probably something extra_spec-like for now b) it will be
>   better when we're expressing requirements and preferences more
>   explicitly (eschewing flavors).
> 
> * There's some concern from some that we should be focussing on the
>   resource tracker doing allocations of the standard compute node
>   resources and the scheduler using the limited list of resource
>   providers, only, and not yet worrying about additional features like
>   custom resource classes. The counter to those concerns is that
>   perhaps we can and should do both?
> 
> [4] https://review.openstack.org/#/c/398469/
> 
> ## Nested Resource Providers
> 
> Percolating and moving forward.[5]
> 
> [5] https://review.openstack.org/#/c/377138/
> 
> ## Make Resource Providers not Remotable
> 
> (This is part of long term work to ensure that the placement service
> is easy to extract.)
> 
> The code[6] is in progress, but there are some questions on how best
> to test or enforce the plan. I've left some clarifying questions that
> I hope Sylvain or someone else can clear up so I can get this
> finished.
> 
> [6] https://review.openstack.org/#/c/404279/
> 
> # Pending Pickup Work
> 
> (Bugs[7], stuff from the leftovers etherpad[8], other random bits of
> improvement.)
> 
> [7] https://bugs.launchpad.net/nova/+bugs?field.tag=placement
> [8] https://etherpad.openstack.org/p/placement-newton-leftovers
> 
> * Demo inventory update script:
>https://review.openstack.org/#/c/382613/
> 
>This one might be considered a WIP because how it chooses to do
>things (rather simply and dumbly) may not be in line with expecations.
> 
> * CORS support in placement API:
>https://review.openstack.org/#/c/392891/
> 
> * Handling limits in schema better
>https://review.openstack.org/#/c/399002/ (needs review)
> 
> * [WIP] Placement api: Add json_error_formatter to defaults
>https://review.openstack.org/#/c/395194/
> 
>This is an effort to avoid boilerplate, but no good solution has
>been determined yet. Reviewers can help us figure a good way to
>hande things.
> 
> * Small improvements to placement.rst
>https://review.openstack.org/#/c/403811/
> 
> * Update the generic resource pools spec to reflect reality
>   https://review.openstack.org/#/c/407562/
> 
> * Do not post allocations that are zero
>   https://review.openstack.org/#/c/407180/
> 
> * Cascade delete of RP aggregate associations
>   https://review.openstack.org/#/c/407707/
> 
> * Improve the error message for failed RC deletion
>   https://review.openstack.org/#/c/406149/
> 
> * Add a retry loop to ResourceClass creation
>   https://review.openstack.org/#/c/399170/
> 
>   There is 

[openstack-dev] [nova] placement/resource providers update 5

[Chris Dent]

A shorter resource provider placement update this week. In part this
is because some of the things to think about from last week[0] got
resolved. What's below is essentially a collection of pending work
related to resource providers and the placement API that needs review
and/or discussion.

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108395.html

# Pending Planned Work

## Update Client Side to Consider Aggregates

After having this in the things to think about section last week,
Jay's posted the start of the resource tracker work[1] which attends
to aggregates. Above that are some placement API changes for getting a
list of resource providers that are members of any of the provided
aggregates.

[1] https://review.openstack.org/#/c/407309/

## Update Scheduler to Request Limited Resource Providers

The debate on GET v POST and which URL to use for filtering resource
providers resolved and the implementation looks good[2]. Once that's
in we can start work on adjust the scheduler, keeping in mind what I
quoted from Jay last week:

   we will only return resource providers to the scheduler that
   are compute nodes in Ocata. the resource providers that the
   placement service returns will either have the resources
   requested or will be associated with aggregates that have
   providers that match the requested resources.

[2] https://review.openstack.org/#/c/392569/

## Docs

I've started a placement_dev.rst[3] (miles to go yet) and will start
on the api-ref soon after that. placement_dev (and its cousin
placement.rst) need some input on what people would like to see in
those files.

[3] https://review.openstack.org/#/c/408313/

## Custom Resource Classes

This is moving along with some of the stack of code[4] having merged.
There was some discussion in IRC worth mentioning:

* There's still an unresolved question on how we are going to express
  certain custom resource class scenarios in build requests,
  especially from the ironic standpoint. The consensus at this point
  is: a) probably something extra_spec-like for now b) it will be
  better when we're expressing requirements and preferences more
  explicitly (eschewing flavors).

* There's some concern from some that we should be focussing on the
  resource tracker doing allocations of the standard compute node
  resources and the scheduler using the limited list of resource
  providers, only, and not yet worrying about additional features like
  custom resource classes. The counter to those concerns is that
  perhaps we can and should do both?

[4] https://review.openstack.org/#/c/398469/

## Nested Resource Providers

Percolating and moving forward.[5]

[5] https://review.openstack.org/#/c/377138/

## Make Resource Providers not Remotable

(This is part of long term work to ensure that the placement service
is easy to extract.)

The code[6] is in progress, but there are some questions on how best
to test or enforce the plan. I've left some clarifying questions that
I hope Sylvain or someone else can clear up so I can get this
finished.

[6] https://review.openstack.org/#/c/404279/

# Pending Pickup Work

(Bugs[7], stuff from the leftovers etherpad[8], other random bits of
improvement.)

[7] https://bugs.launchpad.net/nova/+bugs?field.tag=placement
[8] https://etherpad.openstack.org/p/placement-newton-leftovers

* Demo inventory update script:
   https://review.openstack.org/#/c/382613/

   This one might be considered a WIP because how it chooses to do
   things (rather simply and dumbly) may not be in line with expecations.

* CORS support in placement API:
   https://review.openstack.org/#/c/392891/

* Handling limits in schema better
   https://review.openstack.org/#/c/399002/ (needs review)

* [WIP] Placement api: Add json_error_formatter to defaults
   https://review.openstack.org/#/c/395194/

   This is an effort to avoid boilerplate, but no good solution has
   been determined yet. Reviewers can help us figure a good way to
   hande things.

* Small improvements to placement.rst
   https://review.openstack.org/#/c/403811/

* Update the generic resource pools spec to reflect reality
  https://review.openstack.org/#/c/407562/

* Do not post allocations that are zero
  https://review.openstack.org/#/c/407180/

* Cascade delete of RP aggregate associations
  https://review.openstack.org/#/c/407707/

* Improve the error message for failed RC deletion
  https://review.openstack.org/#/c/406149/

* Add a retry loop to ResourceClass creation
  https://review.openstack.org/#/c/399170/

  There is a race condition in the creation of custom resource clases.

# End

Thanks for reading. Please post questions if you have them.

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Congress] Congress Dashboard and Containers

[Aimee Ukasick]

Thanks Anusha!

I agree that moving the congress_dashboard code to its own repo is a
good idea.

As a workaround, it was suggested to me that I could clone the congress
repo on the same server as horizon, copy the 3 files to the horizon
directory, and then delete the congress code that we don't need (ie,
everything but congress_dashboard). I don't really like that suggestion.
As many companies are moving towards containerized installations, I
think Anusha's suggestion is the best solution.

Please let me know how I can help.


Aimee Ukasick, AT


On 12/08/2016 10:41 PM, Anusha Ramineni wrote:
> Hi Tim, Aimee,
>
> Yes, ideally only congress_dashboard is required on the same server as
> horizon for horizon to discover the plugin, but right now
> congress_dashboard is also part of congress repo, so congress needs to
> be installed on the same server.
>
> I'm thinking for a while to move the repo to separate project, maybe
> its high time we move the congress_dashboard repo to separate project
> like other projects do? wdyt?
> http://docs.openstack.org/developer/horizon/plugin_registry.html
>
>
> Best Regards,
> Anusha
>
> On 9 December 2016 at 03:24, Tim Hinrichs  > wrote:
>
> I wouldn't expect Congress needs to be on the same server as
> Horizon.  Anusha, do you know for sure?
>
> Tim
>
>
> On Thu, Dec 8, 2016 at 1:20 PM Aimee Ukasick
> >
> wrote:
>
> All - we are looking into deploying Congress in its own container,
> separate from the container that OpenStack is in. I know which
> Congress
> dashboard files need to be copied to Horizon, and from what I
> can tell,
> it looks like Congress and Horizon must be running on the same
> server
> for the Congress dashboard to work. Is this assumption correct?
>
>
> Thanks!
>
>
> Aimee Ukasick, AT
>
>
>
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [storlets] Wrapping up big tent work

[eran]

Hi,
We need to go back to the TC.
As you can see in our big tent etherpad  
(https://etherpad.openstack.org/p/storlets-big-tent)

we basically need to merge the below patches:

https://review.openstack.org/409116 Fixing headers across all files
https://review.openstack.org/#/c/394168/ Kestone auth version to v3
https://review.openstack.org/#/c/394437/ Replacing nosetest with test

Thanks,
Eran


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (12/09-12/15)

[Brian Rosmaita]

As discussed at the Glance weekly meeting yesterday, the priorities for
12/1 through 12/8, unfortunately look very similar to last week's
priorities.  Some core reviewers need to step up.  The priorities are:

Highest priority


(1) database strategy for rolling upgrades:
https://review.openstack.org/#/c/331740/
This one has a video to enhance your reviewing pleasure and demonstrate
that the approach described actually is workable:
https://www.youtube.com/watch?v=Z4iwJRlPqOw

(2) glance expand/contract migrations with alembic:
https://review.openstack.org/#/c/374278/
We need another +2 on this one, preferably from a non-Rackspace person.

(3) community images spec update:
https://review.openstack.org/#/c/396919/
New to the list.  The latest patch includes the migration strategy for
which Erno said indicated on the patch he'd change his -2 to a +2, so
don't let the -2 on the patch stop you from reviewing it.

The above three specs need to be reviewed as soon as possible.  We are
blocking Alex and Hemanth, because the Ocata database migration will
handle the community images changes.


Really high priority

(would be highest if the specs were already approved)

(4) Patch to fix a glance_store regression:
https://review.openstack.org/#/c/387719/
and patch to prevent a related backend misconfiguration:
https://review.openstack.org/#/c/388944/

(5) Patch to enable better request-id tracking:
https://review.openstack.org/#/c/352892/
This will be nice for operators, let's get it reviewed and merged!

(6) Request for some insights and opinions for bug
https://bugs.launchpad.net/glance/+bug/1585917


Please take a look
==

(7) glanceclient problem: https://review.openstack.org/#/c/319960/

thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

[Thierry Carrez]

Sean McGinnis wrote:
> On Wed, Dec 07, 2016 at 02:29:03PM +0100, Thierry Carrez wrote:
>>
>> So how about:
>> - we enable an #openstack-meeting-5 to instantly relieve scheduling pressure
>> - we allow teams to hold meetings in their project channel if they want
>> to (and show them all on the meeting agenda through the irc-meetings
>> repo) as long as the channel is logged
>> - we still generally recommend to use meeting rooms whenever possible,
>> so that you can benefit from outside presence and easy mentions/pings
>> - we will proactively add additional meeting rooms when the resource
>> becomes scarce again
> 
> Sounds like a good plan to me.

First step:
https://review.openstack.org/#/q/topic:enable-meeting-5

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][networking-*] Refactor ml2/db file

[Anna Taraday]

Hello everyone!
I'm working on implementation new engine facade in Neutron. [1]   I wrote
before about refactoring segments db code, along with that refactor of
ml2/db.py [2] is also required (to pass context instead of session).
I proposed patch for Neutron and affected
projects(networking-cisco, networking-fortinet, networking-brocade,
networking-vsphere
).
[3]

Kindly, please be aware of these changes.

[1] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
[2] - https://review.openstack.org/#/c/404714/
[3] - https://review.openstack.org/#/q/topic:refactor_ml2db
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] will the release schedule be changed because of PTG?

[Thierry Carrez]

Liyongle (Fred) wrote:
> As we know, OpenStack were released in April and October. Because of the 
> first PTG, Ocata will be released in Feb. I checked [1] and it seems that in 
> the future OpenStack will be released in Feb. and Aug. Is my understanding 
> correct? If not, will it be still in April and October in the future? This is 
> important for us to plan the downstream release. 

Yes, after the Ocata transition, the current plan is to release
OpenStack (every 6 months) late February / early March and late August /
early September.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cloudkitty] IRC Meeting

[as as]

Great, I shall be attending on time. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] broken rally gate

[Andrey Kurilin]

Sorry folks!
We were broken by Keystone, Nova-net, Heat, oslo.db, setuptools(virtualenv)
at one moment and it looks like I made a mistake while trying to fix them
all.

On Fri, Dec 9, 2016 at 3:04 AM, Armando M.  wrote:

>
>
> On 8 December 2016 at 16:40, Armando M.  wrote:
>
>> Hi folks
>>
>> Chasing down why [1] accidentally broke rally. Please do not recheck, and
>> the failure is persistent.
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/408020
>>
>
> https://review.openstack.org/#/c/408870/ should bring sanity back into
> the world.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev