Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Kiall Mac Innes]

We tend to try stick with the various TEST-NET CIDRs etc as well in 
Designate, and document them here:


http://docs.openstack.org/developer/designate/developer-guidelines.html#example-dns-names-and-ip-space

Thanks,
Kiall

On 17/10/16 10:56, TommyLike Hu wrote:
When I handle some stuff related to Manila recently, I found a case 
which may be suitable for Oslo, Anyhow I put it in the maillist so it 
can be discussed before I put it in action.
In testcase, we need a function(maybe 2) to generate random ip address 
(or network), also they should in the range of [1](ipv4 documentation 
range) or [2](ipv6 documentation range), this is the draft code for ipv4:


import six
import random


def rand_ipv4(network=False):
"""This uses the TEST-NET-3 range of reserved IP addresses."""

test_net_3 = '203.0.113.'
if network:
host_length = random.randint(0, 8)
address_segment = random.randint(0, 8 - host_length)
address_segment <<= host_length
address = test_net_3 + six.text_type(address_segment)
address = '/'.join((address,
six.text_type(32 - host_length)))
else:
address = test_net_3 + six.text_type(random.randint(0, 255))
return address

The primary use case here is writing testcases,  I am not sure whether 
it is suitable here, or maybe I misunderstood the intention of 
TEST-NET-3, please leave any comment you like.



[1] https://tools.ietf.org/html/rfc5737
[2] https://tools.ietf.org/html/rfc5156




__
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] Reviewing coverage jobs set up

[Kiall Mac Innes]

On 18/07/16 20:14, Jeremy Stanley wrote:

Note that this will only be true if the change's parent commit in
Gerrit was the branch tip at the time it landed. Otherwise (and
quite frequently in fact) you will need to identify the SHA of the
merge commit which was created at the time it merged and use that
instead to find the post job.

Without wanting to diverge too much from the topic at hand, I believe this
is why those of us who only occasionally want to look at post job output
usually just give up! Keeping this in your head for the once every few
months it's needed is hard ;)

A change being merged is always (AFAIK) part and parcel with a review
being closed, so - why not publish to /post/ (with some
level of dir sharding)?

Thanks,
Kiall


__
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] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Kiall Mac Innes]

Hey Dims,

>From what I remember, oslo.cache seemed unnecessarily complex to use
vs memcache's simplicity, and didn't have any usage docs[1] to help folks
get started using it.

I can see there is some docs under the module index, but at a glance they
seem somewhat disconnected and incomplete.

Are there any complete examples of it's use available for us to compare
against python-memcached and pylibmc etc?

If there comparable functionality and perf wise, I don't see a reason why
projects wouldn't switch. I'll certainly make the effort for Designate if it
looks like the right thing to do.

Thanks,
Kiall

[1]: http://docs.openstack.org/developer/oslo.cache/usage.html


On 13/05/16 12:35, Davanum Srinivas wrote:
> Steve,
>
> Couple of points:
>
> * We can add pylibmc to g-r and phase out python-memcached over a time period.
> * If folks are using python-memcached, we should switch then over to
> oslo.cache, then only oslo.cache will reference either
> python-memcached or pylibmc which will make the situation easier to
> handle.
>
> Thanks,
> Dims
>
> On Fri, May 13, 2016 at 4:14 AM, Steve Martinelli
>  wrote:
>> /me gets the ball rolling
>>
>> Just when python3 support for keystone was looking like a reality, we've hit
>> another snag. Apparently there are several issues with python-memcached in
>> py3, putting it simply: it loads, but doesn't actually work. I've included
>> projects in the subject line that use python-memcached (based on codesearch)
>>
>> Enter pylibmc; apparently it is (almost?) a drop-in replacement, performs
>> better, and is more actively maintained.
>>
>> - Has anyone had success using python-memcached in py3?
>> - Is anyone interested in using pylibmc in their project instead of
>> python-memcached?
>> - Will buy-in from all projects be necessary to proceed for any single
>> project?
>>
>> Open issues like this:
>> https://github.com/linsomniac/python-memcached/issues/94 make me sad.
>>
>> stevemar
>>
>> __
>> 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] [Designate] Tempest Tests - in-repo or separate

[Kiall Mac Innes]

Agreed on a separate repo.

I'm honestly a little unsure how in-service-repo would ever work long
term, given that tempest's requirements will match master, and may
not be compatible with N releases ago's $service requirements..

Thoughts on how that might work, or is it just that no service has had
an in-repo plugin for long enough to hit this yet?

Thanks,
Kiall

On 04/04/16 17:16, Andrea Frittoli wrote:
> I look forward to the first (as far as I know) tempest plugin for a
> service in its own repo! :)
>
>
> On Mon, Apr 4, 2016 at 4:49 PM Hayes, Graham  > wrote:
>
> On 04/04/2016 16:36, Jordan Pittier wrote:
> >
> > On Mon, Apr 4, 2016 at 5:01 PM, Hayes, Graham
> mailto:graham.ha...@hpe.com>
> > >> wrote:
> >
> > As we have started to move to a tempest plugin for our
> functional test
> > suite, we have 2 choices about where it lives.
> >
> > 1 - In repo (as we have [0] currently)
> > 2 - In a repo of its own (something like
> openstack/designate-tempest)
> >
> > There are several advantages to a separate repo:
> >
> > * It will force us to make API changes compatable
> > * * This could cause us to be slower at merging changes [1]
> > * It allows us to be branchless (like tempest is)
> > * It can be its own installable package, and a (much)
> shorter list
> > of requirements.
> >
> > I am not a Designate contributor, but as a Tempest contributor we
> > recommend to use a separate repo. See
> >
> 
> http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin
> > for more details.
>
> Yeap - that was one of the reasons I will leaning towards the separate
> repo. The only thing stopping us was that I cannot see any other
> project
> who does it [2]
>
> We just had a quick discussion in IRC[3] and we are going to go with
> the separate repo anyway.
>
> 2 -
> 
> http://codesearch.openstack.org/?q=%5Etempest&i=nope&files=setup.cfg&repos=
> 3 -
> 
> http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2016-04-04.log.html#t2016-04-04T15:05:38
>
>
> > If everyone is OK with a separate repo, I will go ahead and
> start the
> > creation process.
> >
> > Thanks
> >
> > - Graham
> >
> >
> > 0 - https://review.openstack.org/283511
> > 1 -
> >   
>  
> http://docs.openstack.org/developer/tempest/HACKING.html#branchless-tempest-considerations
> >
> >   
>  
> __
> > 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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Kiall Mac Innes]

On 09/03/16 17:57, Louis Taylor wrote:
> From ChanServ:
>
> 17:55:03 -ChanServ(ChanServ@services.)- Information on #openstack-packaging:
> 17:55:03 -ChanServ(ChanServ@services.)- Registered : Nov 11 18:59:55
> 2011 (4y 17w 0d ago)
> 17:55:03 -ChanServ(ChanServ@services.)- Last used  : (about 75 weeks ago)
> 17:55:03 -ChanServ(ChanServ@services.)- Mode lock  : +imnstf #openstack-stable
> 17:55:03 -ChanServ(ChanServ@services.)- Flags  : KEEPTOPIC
> TOPICLOCK GUARD PRIVATE
> 17:55:03 -ChanServ(ChanServ@services.)- *** End of Info ***
>
> It doesn't look like it's been used in a long time (75 weeks).

For anyone who may try doing this again in the future, don't set the
invite only flag (+i), and
then the +f #openstack-stable will trigger a redirect to the new channel.

Thanks,
Kiall


__
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] [designate] The designate API service is stopped

[Kiall Mac Innes]

So, I see three things of interest in the logs here.

1) The SIGHUP signal received

> 2015-07-28 14:49:10.378 22487 INFO oslo_service.service [-] Caught
> SIGHUP, exiting

Do we know what's sending this to signal to Designate?

2) The first exception, "Calling waitall() ..."

> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> AssertionError: Calling waitall() from within one of the GreenPool's
> greenthreads will never terminate.

We believe this to be effectively harmless, though still an open bug:

https://bugs.launchpad.net/designate/+bug/1442141

3) The second exception, "Could not bind ..."

> 2015-07-28 14:49:40.445 22487 ERROR oslo_service.threadgroup [-] Could
> not bind to 0.0.0.0:9001  after trying for 30 seconds

What kernel version are you running?

Can you try:

a) Removing the socket.SO_REUSEADDR option from the API socket

Approx L211 of designate/service.py, comment this line out:

> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

b) Putting socket.SO_REUSEADDR back in, and adding socket.SO_REUSEPORT.

This will need a 3.9+ kernel. Approx L211 of designate/service.py, add
this line:

> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)


Thanks,
Kiall


On 29/07/15 09:35, Jaime Fernández wrote:
> Hi Kiall,
> 
> We haven't found the cause yet. Even moving the host to the same
> network, the error still happens :(
> 
> We decided to migrate to rabbitmq. While migrating OST to rabbitmq, I've
> connected to the local rabbitmq, and I've also seen the same problem
> (all designate processes and rabbitmq in the same host). In this
> occasion, the designate-api process died after 5 hours.
> 
> Here it is the logs:
> 
> 2015-07-28 12:37:52.730 22487 INFO eventlet.wsgi
> [req-84e3674a-860e-46bf-b7a7-b9866866152d noauth-user
> 4e3b6c0108f04b309737522a9deee9d8 - - -] 127.0.0.1 - - [28/Jul/2015
> 12:37:52] "GET /v1/domains/38f8f79d-0f6c-42fb-abd7-98ae8cc87fc5/records
> HTTP/1.1" 200 1757 0.049479
> 2015-07-28 14:49:10.378 22487 INFO oslo_service.service [-] Caught
> SIGHUP, exiting
> 2015-07-28 14:49:10.379 22487 INFO designate.service [-] Stopping api
> service
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup [-] Error
> stopping thread.
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup Traceback
> (most recent call last):
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/oslo.service-0.4.0-py2.7.egg/oslo_service/threadgroup.py",
> line 107, in _stop_threads
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup x.stop()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/oslo.service-0.4.0-py2.7.egg/oslo_service/threadgroup.py",
> line 48, in stop
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> self.thread.kill()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 240, in kill
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup return
> kill(self, *throw_args)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 294, in kill
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> g.throw(*throw_args)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 214, in main
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup result
> = function(*args, **kwargs)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/designate/service.py", line 230, in
> _wsgi_handle
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> log=loggers.WritableLogger(logger))
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/wsgi.py",
> line 842, in server
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> pool.waitall()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenpool.py",
> line 117, in waitall
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> "Calling waitall() from within one of the " \
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> AssertionError: Calling waitall() from within one of the GreenPool's
> greenthreads will never terminate.

Re: [openstack-dev] [designate] The designate API service is stopped

[Kiall Mac Innes]

Interesting, It would be great to know what causes the crash if you can 
identify it.


What was previously between the designate components and qpid? Simple 
router? Stateful firewall? Something else?


Thanks,
Kiall

On 22/07/15 10:53, Jaime Fernández wrote:
I moved the virtual machine where designate processes are running into 
a host in the same LAN than OST. Now the designate-api process does 
not die anymore (still using qpid). I'm afraid that some network 
problem or timeout could be the reason for this problem. We'll keep 
monitoring this process to confirm it.


I understand that it's a bug of designate-api or oslo.messaging library.

On Tue, Jul 21, 2015 at 1:19 PM, Jaime Fernández > wrote:


Hi Kiall,

It's a bit strange because only designate-api dies but
designate-sink is also integrated with qpid and survives.

These issues are a bit difficult because it is not deterministic.
What I've just tested is using a local qpid instance and it looks
like the designate-api is not killed any more (however, it's a
short period of time). We are going to integrate the host where
designate components are installed in the same VLAN than the rest
of OST just to check if it's a rare issue with the network.

Before testing with Rabbit, as you recommended, we are testing
with qpid in the same VLAN (just to discard the network issue).

I will give you info about my progress.




__
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] Python 3: 5 more projects with a py34 voting gate, only 4 remaing

[Kiall Mac Innes]

You can (nearly) add Designate to this list :)

Pradeep has been doing a great job getting the codebase py3 compatible!

Thanks,
Kiall

On 17/07/15 12:32, Victor Stinner wrote:
> Hi,
> 
> We are close to having a voting py34 gate on all OpenStack libraries and
> applications. I just made the py34 gate voting for the 5 following
> projects:
> 
> * keystone
> * heat
> * glance_store: Glance library (py34 is already voting in Glance)
> * os-brick: Cinder library (py34 is already voting in Cinder)
> * sqlalchemy-migrate
> 
> 
> A voting py34 gate means that we cannot reintroduce Python 3 regressions
> in the code tested by "tox -e py34". Currently, only a small subset of
> test suites is executed on Python 3.4, but the subset is growing
> constantly and it already helps to detect various kinds of Python 3 issues.
> 
> Sirushti Murugesan (who is porting Heat to Python 3) and me proposed a
> talk "Python 3 is coming!" to the next OpenStack Summit at Tokyo. We
> will explain the plan to port OpenStack to Python in depth.
> 
> 
> There are only 4 remaining projects without py34 voting gate:
> 
> (1) swift: I sent patches, see the "Fix tox -e py34" patch:
> 
> https://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:py3,n,z
> 
> 
> 
> (2) horizon: I sent patches:
> 
> https://review.openstack.org/#/q/topic:bp/porting-python3+project:openstack/horizon,n,z
> 
> 
> 
> (3) keystonemiddleware: blocked by python-memcached, I sent a pull
> request 3 months ago and I'm still waiting...
> 
> https://github.com/linsomniac/python-memcached/pull/67
> 
> I may fork the project if the maintainer never reply. Read the current
> thread "[all] Non-responsive upstream libraries (python34 specifically)"
> on openstack-dev.
> 
> 
> (4) python-savannaaclient: "We haven't enough tests to ensure that
> savanna client works correctly on py33, so, it's kind of premature step.
> We already have py33 and pypy jobs in experimental pipeline." This
> client can be ported later.
> 
> 
> Note: The py34 gate of oslo.messaging is currently non voting because of
> a bug in Python 3.4.0, fix not backported to Ubuntu Trusty LTS yet:
> 
> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907
> 
> The bug was fixed in Python 3.4 in May 2014 and was reported to Ubuntu
> in September 2014.
> 
> Victor
> 
> __
> 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] [designate] The designate API service is stopped

[Kiall Mac Innes]

Inline.

Thanks,
Kiall

On 21/07/15 09:24, Jaime Fernández wrote:
> I confirm that it happened again. I started all the designate processes
> and after an hour (approximately), the designate-api process died with
> the same stack trace.
> 
> Restarting the designate-api does not help because API requests are not
> replied any more (timeouts):
> 2015-07-21 10:12:53.463 4403 ERROR designate.api.middleware
> [req-281e9665-c49b-43e0-a5d0-9a48e5f52aa1 noauth-user noauth-project - -
> -] Timed out waiting for a reply to message ID
> 19cda11c089f43e2a43a75a5851926c8

This suggests the API service is back up and running, but either your
message broker (qpid), or the target service (designate-central) is down.

> 
> When the designate-api process dies, I need to restart all the designate
> processes. Then the api works correctly until the process dies again.

This leads me to believe qpid is somehow responsible, but, I don't have
any concrete reasons to believe that. Simply a gut feeling! If all
services need to be restarted, then it's most likely a shared resource
that's failing, mis-configured, or somehow incompatible with Designate.
I've never seen anything like this before :/

> 
> I consider that it's normal the hex dump for qpid (it is debug level)
> although I noticed it was different in rabbitmq.
> 
> We have deployed designate in an Ubuntu host, as installation
> instructions recommended, and I don't think there is any security issue
> to stop the service. In fact, the trace is really strange because the
> api was already bound on port 9001. Our Openstack platform is supported
> by RedHat and that's why we need to integrate with qpid.
> 
> I will try a couple of different scenarios:
> a) Use a qpid local instance (instead of OST qpid instance)
> b) Use a rabbitmq local instance

Can you try with RabbitMQ? It's really the only one we test, but it's
all hidden behind the oslo.messaging library, so I can't think of any
good reason why one would work and the other doesn't. If this works,
I'll test out with qpid and see if there's anything obvious.

> 
> On Mon, Jul 20, 2015 at 5:20 PM, Kiall Mac Innes  <mailto:ki...@macinnes.ie>> wrote:
> 
> Side Question: Is is normal for QPid to log all the
> "\x0f\x01\x00\x14\x00\x01\x00\x00\x00\x00\x00"'s etc?
> 
> I'm guessing that, since you're using qpid, you're also on RedHat. Could
> RH's SELinux policies be preventing the service from binding to
> tcp/9001?
> 
> If you start as root, do you see similar issues?
> 
> Thanks,
> Kiall
> 
> On 20/07/15 15:48, Jaime Fernández wrote:
> > Hi Tim,
> >
> > I only start one api process. In fact, when I say that the api process
> > dies, I don't have any designate-api process and there is no process
> > listening on the 9001 port.
> >
> > When I started all the designate processes, the API worked correctly
> > because I had tested it. But after some inactivity period (a couple of
> > hours, or a day), then the designate-api process died. It is not
> > possible that the process has been restarted during this time.
> >
> > I've just started the process again and now it works. I will check if it
> > dies again and report it.
> >
> >
> > Thanks
> >
> > On Mon, Jul 20, 2015 at 4:24 PM, Tim Simmons  <mailto:tim.simm...@rackspace.com>
> > <mailto:tim.simm...@rackspace.com <mailto:tim.simm...@rackspace.com>>> 
> wrote:
> >
> > Jaime,
> >
> >
> > Usually that's the error you see if you're trying to start up
> > multiple API processes. They all try and bind to port 9001, so that
> > error is saying the API can't bind. So something else (I suspect
> > another designate-api process, or some other type of API) is already
> > listening on that port.
> >
> >
> > Hope that helps,
> >
> > Tim Simmons
> >
> >
> >   
>  
> > *From:* Jaime Fernández  <mailto:jjja...@gmail.com> <mailto:jjja...@gmail.com
> <mailto:jjja...@gmail.com>>>
> > *Sent:* Monday, July 20, 2015 8:54 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* [openstack-dev] [designate] The designate API
> service is
> > stopped
> >
> > I

Re: [openstack-dev] DNS and Designate mid-cycle meet-up - August in Austin

[Kiall Mac Innes]

Got my ticket, thanks Joe / Rackspace for hosting this :)

Thanks,
Kiall

On 20/07/15 18:05, Joe Mcbride wrote:
> Hello,
> The Designate team will hold it's mid-cycle meet-up in August, details below.
>  - Dates: August 17 to 20, 2015
>  - Location: Austin TX
>  - Registration/agenda: 
> http://www.eventbrite.co.uk/e/openstack-designate-2015-summer-mid-cycle-meetup-tickets-17833181526
>  - Remote attendees are welcome and will be accommodated via Google Hangout.
> 
> Learn more about Designate:
>  - Docs: http://docs.openstack.org/developer/designate/getting-started.html
>  - Wiki: https://wiki.openstack.org/wiki/Designate
>  - IRC: #openstack-dns (everyday) and Wednesday @17:00UTC on 
> #openstack-meeting-alt
> __
> 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] [designate] The designate API service is stopped

[Kiall Mac Innes]

Side Question: Is is normal for QPid to log all the
"\x0f\x01\x00\x14\x00\x01\x00\x00\x00\x00\x00"'s etc?

I'm guessing that, since you're using qpid, you're also on RedHat. Could
RH's SELinux policies be preventing the service from binding to tcp/9001?

If you start as root, do you see similar issues?

Thanks,
Kiall

On 20/07/15 15:48, Jaime Fernández wrote:
> Hi Tim,
> 
> I only start one api process. In fact, when I say that the api process
> dies, I don't have any designate-api process and there is no process
> listening on the 9001 port.
> 
> When I started all the designate processes, the API worked correctly
> because I had tested it. But after some inactivity period (a couple of
> hours, or a day), then the designate-api process died. It is not
> possible that the process has been restarted during this time.
> 
> I've just started the process again and now it works. I will check if it
> dies again and report it.
> 
> 
> Thanks
> 
> On Mon, Jul 20, 2015 at 4:24 PM, Tim Simmons  > wrote:
> 
> Jaime,
> 
> 
> Usually that's the error you see if you're trying to start up
> multiple API processes. They all try and bind to port 9001, so that
> error is saying the API can't bind. So something else (I suspect
> another designate-api process, or some other type of API) is already
> listening on that port.
> 
> 
> Hope that helps,
> 
> Tim Simmons
> 
> 
> 
> *From:* Jaime Fernández mailto:jjja...@gmail.com>>
> *Sent:* Monday, July 20, 2015 8:54 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [designate] The designate API service is
> stopped
>  
> I've followed instructions to install Designate in Dev environment:
> http://docs.openstack.org/developer/designate/install/ubuntu-dev.html
> 
> I've made some slight modifications to use qpid (instead of
> rabbitmq) and to integrate with Infoblox.
> 
> What I've seen is that designate-api process dies (the other
> processes are running correctly). I'm not sure if the problem could
> be a network issue between designate-api and qpid.
> 
> Here it is the output for last traces of designate-api process:
> 
> 2015-07-20 14:43:37.728 727 DEBUG qpid.messaging.io.raw [-]
> READ[3f383f8]:
> '\x0f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x01\n\x00\x00'
> readable
> 
> /home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/qpid/messaging/driver.py:411
> 2015-07-20 14:43:37.729 727 DEBUG qpid.messaging.io.ops [-]
> RCVD[3f383f8]: ConnectionHeartbeat() write
> 
> /home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/qpid/messaging/driver.py:651
> 2015-07-20 14:43:37.729 727 DEBUG qpid.messaging.io.ops [-]
> SENT[3f383f8]: ConnectionHeartbeat() write_op
> 
> /home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/qpid/messaging/driver.py:683
> 2015-07-20 14:43:37.730 727 DEBUG qpid.messaging.io.raw [-]
> SENT[3f383f8]:
> '\x0f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x01\n\x00\x00'
> writeable
> 
> /home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/qpid/messaging/driver.py:475
> Traceback (most recent call last):
>   File
> 
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/hubs/hub.py",
> line 457, in fire_timers
> timer()
>   File
> 
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/hubs/timer.py",
> line 58, in __call__
> cb(*args, **kw)
>   File
> 
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 214, in main
> result = function(*args, **kwargs)
>   File
> 
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/oslo.service-0.4.0-py2.7.egg/oslo_service/service.py",
> line 623, in run_service
> service.start()
>   File "/home/sysadmin/openstack/designate/designate/service.py",
> line 173, in start
> socket = self._wsgi_get_socket()
>   File "/home/sysadmin/openstack/designate/designate/service.py",
> line 209, in _wsgi_get_socket
> 'port': self._service_config.api_port})
> RuntimeError: Could not bind to 0.0.0.0:9001 
> after trying for 30 seconds
> 2015-07-20 14:43:55.221 727 ERROR oslo_service.threadgroup [-] Could
> not bind to 0.0.0.0:9001  after trying for 30
> seconds
> 2015-07-20 14:43:55.221 727 ERROR oslo_service.threadgroup Traceback
> (most recent call last):
> 2015-07-20 14:43:55.221 727 ERROR oslo_service.threadgroup   File
> 
> "/home/sysadm

[openstack-dev] [designate] PTL Candidacy

[Kiall Mac Innes]

I would like to announce my candidacy for Designate / DNS Services
Program PTL position for the Liberty cycle.

Keeping this short! I've been working on the Designate project since day
1, and believe we've made great progress over the last few cycles. For
Liberty, I expect our focus will be on tighter integration with other
OpenStack projects, scalability and reliability improvements, and
community growth.

Thanks,
Kiall

__
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] Multi Region Designate

[Kiall Mac Innes]

Hey Anik,

So, unlike Nova or other services which really are "region" aware,
Designate, being designed to push data into the global DNS namespace,
doesn't have the same concept of regions.

Typically, you will either have regions which are "close enough" to run
a Galera/Percona cluster across them without adding too much latency, or
you will run asynchronous replication from one region to another using
an Active/Standby failover for the core DB.

The DNS team @ HP has discussed possible improvements to this many times
over the last year or so, but haven't come up with any great solutions
to providing what amounts to a global service is a per-region way. We're
certainly open to suggestions! :)

Thanks,
Kiall

On 23/03/15 04:41, Anik wrote:
> Hi,
> 
> Are there any plans to have multi region DNS service through designate ?
> 
> For example If a tenant has projects in multiple regions and wants to
> use a single (flat) external domain name space for floating IPs, what is
> the proposed solution for such a use case using Designate ?
>  
> Regards,
> Anik
> 
> 
> __
> 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] [infra] What do people think of YAPF (like gofmt, for python)?

[Kiall Mac Innes]

I have no clue how I managed to send that last email encrypted -
Apologies :)

Re YAPF, or autofomatting, I've very little opinion..

But - I gave YAPF a go against the Designate codebase with the stock config:

  258 files changed, 5242 insertions(+), 5691 deletions(-)

Getting changes like that into the various projects won't be easy, even
if the core team is happy to just +A without reviewing for potential
issues, a massive percentage of in-progress reviews will fail to merge
and need manual rebasing.

For companies with internal forks/patches - those will likely all have
to be redone too..

I'm not sure there's really a good solution to this

Thanks,
Kiall


On 26/03/15 16:38, Kiall Mac Innes wrote:
> 
> 
> __
> 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] [infra] What do people think of YAPF (like gofmt, for python)?

[Kiall Mac Innes]

binv2ijTsg9Fd.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
__
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] [tooz] 1.0 goals

[Kiall Mac Innes]

On 09/03/15 13:56, Julien Danjou wrote:
> Hi fellow developers,
> 
> It'd be nice to achieve a 1.0 release for tooz, as some projects are
> already using it, and more are going to adopt it.
> 
> I think we should collect features and potential bugs/limitations we'd
> like to have and fix before that. Ideas, thoughts?
> 
> Cheers,
> 

Funnily enough, We just started looking at tooz for Designate -
specifically hoping for functionality similar to Kazoo's partitioner[1].

For our metering and billing use case, we'll need to periodically emit
and "dns.zone.exists" event for every zone, unlike for example nova
where nova-compute handles this, and the # of events it needs to emit
each hour is bounded by the number of VMs you can squeeze onto a single
compute node, there can be millions of zones owned by a single node.
Having something like Kazoo's partitioner would certainly help here!

Thanks,
Kiall

[1]: http://kazoo.readthedocs.org/en/latest/api/recipe/partitioner.html



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [Keystone] How to check admin authentication?

[Kiall Mac Innes]

On 02/03/15 08:53, Dmitry Tantsur wrote:
2015-02-27 17:27 GMT+01:00 Dolph Mathews >:



On Fri, Feb 27, 2015 at 8:39 AM, Dmitry Tantsur
mailto:dtant...@redhat.com>> wrote:

Hi all!

This (presumably) pretty basic question tortures me for
several months already, so I kindly seek for help here.

I'm working on a Flask-based service [1] and I'd like to use
Keystone tokens for authentication. This is an admin-only API,
so we need to check for an admin role. We ended up with code
[2] first accessing Keystone with a given token and
(configurable) admin tenant name, then checking 'admin' role.
Things went well for a while.

Now I'm writing an Ironic driver accessing API of [1]. Pretty
naively I was trying to use an Ironic service user
credentials, that we use for accessing all other services. For
TripleO-based installations it's a user with name 'ironic' and
a special tenant 'service'. Here is where problems are. Our
code perfectly authenticates a mere user (that has tenant
'admin'), but asks Ironic to go away.

We've spent some time researching documentation and keystone
middleware source code, but didn't find any more clues.
Neither did we find a way to use keystone middleware without
rewriting half of project. What we need is 2 simple things in
a simple Flask application:
1. validate a token
2. make sure it belongs to admin


I'm not really clear on what problem you're having, because I'm
not sure if you care about an "admin" username, "admin" tenant
name, or "admin" role name. If you're implementing RBAC, you only
really need to care about the user have an "admin" role in their
list of roles.


Yeah, I guess that's what I need.


It's probably worth calling out that, the Keystone middleware itself 
doesn't have any concept of "admin" built in (and this is a good 
thing!). Your nova admins may be a totally different group of people to 
your Swift admins. Instead, the Keystone middleware will simply tell you 
the facts about the user/tenant making the API call, their username, 
tenant_id/project_id, the list of roles assigned to them etc. Given this 
information, most OpenStack projects use the oslo policy library to take 
this info, apply some rules, and then allow you to ask "Can the user 
perform action X?" rather than "Is this user an admin?".


For a small internal project, this kind of flexibility may not matter, 
and it's certainly not required to use the KS middleware.. But if you're 
trying to dig through the various projects codebase's to see how things 
are done, knowing this will help :)




You can wrap your flask application with a configured instance of
auth_token middleware; this is about the simplest way to do it,
and this also demos the environment variables exposed to your
application that you can use to validation authorization:


https://github.com/dolph/keystone-deploy/blob/master/playbooks/roles/http/templates/echo.py#L33-L41


Thanks a lot, I will give it a try!


If you happen to be using paste-deploy with Flask, Designate has some 
code that does just that..


We use a piece of WSGI Middleware[1] to read the info provided by the 
keystone middleware and attach it to the Request object for later use, 
and the api-paste.ini itself[2] to wire up the KS middleware, our 
KeystoneContextMiddleware" and the Flask app itself.


[1]: 
https://github.com/openstack/designate/blob/master/designate/api/middleware.py#L62-119
[2]: 
https://github.com/openstack/designate/blob/master/etc/designate/api-paste.ini


Good luck!

Thanks,
Kiall
__
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] [Designate] Core reviewer update

[Kiall Mac Innes]

Changes have been applied, welcome Tim :)

On 12/02/15 16:18, Rich Megginson wrote:
> On 02/12/2015 08:51 AM, Hayes, Graham wrote:
>> On 12/02/15 15:50, Kiall Mac Innes wrote:
>>> +1 - Tim has been giving good reviews over the last few months and will
>>> make a good addition..
>>>
>>> Thanks,
>>> Kiall
>>>
>>> On 12/02/15 15:40, Vinod Mangalpally wrote:
>>>> Hello Designate folks,
>>>>
>>>> Betsy Luzader (betsy) resigned from her core reviewer position on
>>>> Designate. In order to keep the momentum of reviews in Designate going,
>>>> I'd like to propose adding Tim Simmons (timsim) to designate-core.
>>>>
>>>> For context on Designate reviews and who has been active, please
>>>> see http://stackalytics.com/report/contribution/designate-group/30
>>>>
>>>> Designate members, please reply with your vote on the proposed change.
>>>>
>>>> Thanks
>>>> vinod
>>>>
>> +1 - I think Tim will make a great addition :)
> 
> +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
>>>>
>>
>> __
>>
>> 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



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [Designate] Core reviewer update

[Kiall Mac Innes]

+1 - Tim has been giving good reviews over the last few months and will
make a good addition..

Thanks,
Kiall

On 12/02/15 15:40, Vinod Mangalpally wrote:
> Hello Designate folks,
> 
> Betsy Luzader (betsy) resigned from her core reviewer position on
> Designate. In order to keep the momentum of reviews in Designate going,
> I'd like to propose adding Tim Simmons (timsim) to designate-core.
> 
> For context on Designate reviews and who has been active, please
> see http://stackalytics.com/report/contribution/designate-group/30
> 
> Designate members, please reply with your vote on the proposed change.
> 
> Thanks
> vinod
> 
> 
> __
> 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
> 



signature.asc
Description: OpenPGP digital 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