Re: [openstack-dev] [designate] Status of the project

2017-02-14 Thread Hayes, Graham
On 11/02/17 15:12, Andrea Frittoli wrote:
> 
> 
> On Thu, Feb 9, 2017 at 7:22 PM Hayes, Graham  > wrote:
> 
> The HTML version of this is here:
> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
> 
> I have been asked a few times recently "What is the state of the
> Designate
> project?", "How is Designate getting on?", and by people who know
> what is
> happening "What are you going to do about Designate?".



> 
> We also need help from cross project teams - the work done by them is
> brilliant
> but it can be hard for smaller projects to consume. We have had a lot of
> progress since the `Leveller Playing Field`_ debate, but a lot of
> work is
> still optimised for the larger teams who get direct support, or well
> resourced
> teams who can dedicate people to the implementation of plugins / code.
> 
> 
> The QA team is committed to serve every single project in big tent
> community.
> Please reach out to us on IRC in #openstack-qa or add an item to the QA
> meeting agenda.
> We are a rather small team ourselves, so we won't be able to implement
> things on project
> team's behalf, but we'll do our best to help.
> 
> andrea
> 

While this may be the intention, it is definitely not the reality. Some
projects do have the work done for them by the QA team - and as I said,
it is generally the larger teams that could afford to take the load vs
the smaller teams that struggle.

A perfect example happened yesterday.

Grenade was being tested for Ocata -> Pike upgrade, before the jobs on
master was updated. As part of this change Keystone moved from v2 to v3.

This caused an issue in 2 in-tree grenade projects (Nova and Cinder)
due to a behavior difference in the OpenStack CLI [0]

This issue was fixed in tree for these projects, before they knew
there was a problem, but projects that have grenade plugins didn't find
out until our gate failed, and started blocking patches.

This then meant 30-40 mins or so of debugging the logs, finding the bug,
writing a fix, then waiting for the the patch to merge.

I wouldn't even ask for a fix to be coded for us - just an email
with "you need to make sure your grenade plugin adds a role to
the user you create from Pike onwards" would have saved a lot
of time.

I understand that the QA team focuses on the core projects
more - that is just how OpenStack operates, but just being
mindful of projects that use things like devstack, grenade,
tempest etc as plugin may not get the fixes that happen for
the core.

- Graham

0 - https://bugs.launchpad.net/keystone/+bug/1662911


> 
> __
> 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] Status of the project

2017-02-11 Thread Clint Byrum
Excerpts from Joshua Harlow's message of 2017-02-10 11:07:29 -0800:
> Fox, Kevin M wrote:
> > I'd say kube-dns and designate are very different technologies.
> >
> > kube-dns is a service discovery mechanism for kubernetes intend to provide 
> > internal k8s resolution. The fact it uses dns to implement service 
> > discovery is kind of an implementation detail, not its primary purpose. 
> > There's no need for private dns management, scaling past the size of the 
> > k8s cluster itself, etc. A much easier problem to solve at the moment.
> >
> > Designate really is a multitenant dns as a service implementation. While it 
> > can be used for service discovery, its not its primary purpose.
> >
> > I see no reason they couldn't share some common pieces, but care should be 
> > given not to just say, lets throw out one for the other, as they really are 
> > different animals.
> >
> 
> Arg, the idea wasn't meant to be that (abandon one for the other), but 
> just to investigate the larger world and maybe we have to adapt our 
> model of `multitenant dns as a service implementation` to be slightly 
> different; so what..., if it means we get to keep contributors and grow 
> a larger community (and partner with others and learn new things and 
> adopt new strategies/designs and push the limits of tech and ...) by 
> doing so then that's IMHO good.
> 

Perhaps Designate could go looking for a larger community outside of
OpenStack. One of the problems with tightly integrating in the OpenStack
paradigm is that we only see our way of thinking. For instance, we have
a access to a user base without trying since OpenStack users will always
look for an OpenStack project first. But there may very well be users
out there who do have multi-tenant DNS needs, but they don't want
Keystone et.al.

With a few tweaks, any service provider that doesn't have a good DNSaaS
but needs one, multi or single tenant, could have Designate, and that
would invite quite a bit more contribution.

I have no idea what the potential community size is, but it sounds like
"not 0", and given that it sounds like Designate just needs a couple
more active developers, so perhaps it's worth socializing externally.

__
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] Status of the project

2017-02-11 Thread Andrea Frittoli
On Thu, Feb 9, 2017 at 7:22 PM Hayes, Graham  wrote:

> The HTML version of this is here:
> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>
> I have been asked a few times recently "What is the state of the Designate
> project?", "How is Designate getting on?", and by people who know what is
> happening "What are you going to do about Designate?".
>
> Needless to say, all of this is depressing to me, and the people that I
> have
> worked with for the last number of years to make Designate a truly useful,
> feature rich project.
>
> *TL;DR;* for this - Designate is not in a sustainable place.
>
> To start out - Designate has always been a small project. DNS does not have
> massive *cool* appeal - its not shiny, pretty, or something you see on the
> front page of HackerNews (unless it breaks - then oh boy do people
> become DNS
> experts).
>
> A line a previous PTL for the project used to use, and I have happily
> robbed is
> "DNS is like plumbing, no one cares about it until it breaks, and then
> you are
> standing knee deep in $expletive". (As an aside, that was the reason we
> chose
> the crocodile as our mascot - its basically a dinosaur, old as dirt, and
> when
> it bites it causes some serious complications).
>
> Unfortunately that comes over into the development of DNS products
> sometimes.
> DNSaaS is a check box on a tender response, an assumption.
>
> We were lucky in the beginning - we had 2 large(ish) public clouds that
> needed
> DNS services, and nothing currently existed in the eco-system, so we got
> funding for a team from a few sources.
>
> We got a ton done in that period - we moved from a v1 API which was
> synchronous to a new v2 async API, we massively increased the amount of DNS
> servers we supported, and added new features.
>
> Unfortunately, this didn't last. Internal priorities within companies
> sponsoring the development changed, and we started to shed contributors,
> which
> happens, however disappointing. Usually when this happens if a project is
> important enough the community will pick up where the previous group
> left off.
>
> We have yet to see many (meaningful) commits from the community though. We
> have some great deployers who will file bugs, and if they can put up patch
> sets - but they are (incredibly valuable and appreciated) tactical
> contributions. A project cannot survive on them, and we are no exception.
>
> So where does that leave us? Let have a look at how many actual commits we
> have had:
>
> Commits per cycle
>
>  +--+-+
>  | Havana   | 172 |
>  +--+-+
>  | Icehouse | 165 |
>  +--+-+
>  | Juno | 254 |
>  +--+-+
>  | Kilo | 340 |
>  +--+-+
>  | Liberty  | 327 |
>  +--+-+
>  | Mitaka   | 246 |
>  +--+-+
>  | Newton   | 299 |
>  +--+-+
>  | Ocata| 98  |
>  +--+-+
>
> Next cycle, we are going to have 2 community goals:
>
> * Control Plane API endpoints deployment via WSGI
> * Python 3.5 functional testing
>
> We would have been actually OK for the tempest one - we were one of the
> first
> external repo based plug-ins with `designate-tempest-plugin`_
>
> For WSGI based APIs, this will be a chunk of work - due to our internal
> code
> structure splitting out the API is going to be ... an issue. (and I think
> it
> will be harder than most people expect - anyone using olso.service has
> eventlet imported - I am not sure how that affects running in a WSGI
> server)
>
> Python 3.5 - I have no idea. We can't even run all our unit tests on python
> 3.5, so I suspect getting functional testing may be an issue. And,
> convincing
> management that re-factoring parts of the code base due to "community
> goals"
> or a future potential pay-off can be more difficult than it should.
>
>   http://graham.hayes.ie/images/oct-2016-projects-prod.jpg
>
> We now have a situation where the largest "non-core" project [1]_ in the
> tent
> has a tiny number of developers working on it. 42% of deployers are
> evaluating
> Designate, so we should see this start to increase.
>
> How did this happen?
> 
>
> Like most situations, there is no single cause.
>
> Certainly there may have been fault on the side of the Designate
> leadership.
> We had started out as a small team, and had built a huge amount of trust
> and
> respect based on in person interactions over a few years, which meant that
> there was a fair bit of "tribal knowledge" in the heads of a few people,
> and
> that new people had a hard time becoming part of the group.
>
> Also, due to volume of work done by this small group, a lot of users /
> distros
> were OK leaving us work - some of us were also running a production
> designate
> service 

Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Jeremy Stanley
On 2017-02-10 17:47:50 + (+), Hayes, Graham wrote:
[...]
> I am struggling to think of even one) multi tenant DNS management
> APIs.
[...]

I ran http://www.nictool.com/ at a service provider years ago,
selected specifically because it's a multi-tenant (or at least could
be made reasonably so via RBAC) authoritative DNS manglement
frontend with a usable API. The AGPL license on it would probably
make it unsuitable for a lot of our downstream ecosystem however.

If anything, I see that (and the struggle I went through back then
to find anything remotely close to fitting that use case) as an
explanation for why Designate exists. There just isn't a lot out
there focused on this problem space except what random service
providers have written in-house, and the vast majority of them never
see the light of (free software) day.
-- 
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


Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Brandon B. Jozsa
I’m just catching up with this thread, but I absolutely agree with Jay on 
documentation and just general messaging. This is not just a Designate issue at 
all though, this is an issue that many projects have. Well drafted specs, 
mission, scope, and general messaging are sometimes the bane of great ideas or 
projects. The more solid the documentation is, and to that point installation 
guides, the better people will understand the value of the project. Sure DNS 
isn’t the sexiest thing out there, but if you make it more secure and more 
stable as a service element…I think we’d all agree, that provides very high 
value.

If there’s a way that our teams can help, let us know (or reach out to me 
directly).

Brandon



On February 9, 2017 at 9:35:55 PM, Jay Pipes 
(jaypi...@gmail.com) wrote:

On 02/09/2017 02:19 PM, Hayes, Graham wrote:


> Where too now then?
> ===
>
> Well, this is where I call out to people who actually use the project -
> don't
> jump ship and use something else because of the picture I have painted.
> We are
> a dedicated team, how cares about the project. We just need some help.
>
> I know there are large telcos who use Designate. I am sure there is tooling,
> or docs build up in these companies that could be very useful to the
> project.
>
> Nearly every commercial OpenStack distro has Designate. Some have had it
> since
> the beginning. Again, developers, docs, tooling, testers, anything and
> everything is welcome. We don't need a massive amount of resources - we
> are a
> small ish, stable, project.
>
> We need developers with upstream time allocated, and the budget to go to
> events
> like the PTG - for cross project work, and internal designate road map,
> these
> events form the core of how we work.
>
> We also need help from cross project teams - the work done by them is
> brilliant
> but it can be hard for smaller projects to consume. We have had a lot of
> progress since the `Leveller Playing Field`_ debate, but a lot of work is
> still optimised for the larger teams who get direct support, or well
> resourced
> teams who can dedicate people to the implementation of plugins / code.
>
> As someone I was talking to recently said - AWS is not winning public cloud
> because of commodity compute (that does help - a lot), but because of the
> added services that make using the cloud, well, cloud like. OpenStack
> needs to
> decide that either it is just compute, or if it wants the eco-system. [5]_
> Designate is far from alone in this.



Graham, thank you for the heartfelt post. I may not agree with all your
points, but I know you're coming from the right place and truly want to
see Designate (and OpenStack in general) succeed.

Your point about smaller projects finding it more difficult to "consume"
help from cross-project teams is an interesting one. When the big tent
was being discussed, I remember the TC specifically discussing a change
for cross-project team focus: moving from a "we do this work for you"
role to a "we help you do this work for yourself" role. You're correct
that the increase in OpenStack projects meant that the cross-project
teams simply would not be able to continue to be a service to other
teams. This was definitely predicted during the big tent discussions.

If I had one piece of advice to give Designate, it would be to
prioritize getting documentation (both installation as well as dev-ref
and operational docs) in good shape. I know writing docs sucks, but docs
are a springboard for users and contributors alike and can have a
multiplying effect that's difficult to overstate. Getting those install
and developer docs started would enable the cross-project docs team to
guide Designate contributors in enhancing and cleaning up the docs and
putting some polish on 'em. Your idea above that maybe some users
already wrote some docs is a good one. Maybe reach out personally to
those telcos and see if they can dig something up that can be the basis
for upstream docs.

Best,
-jay



__
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] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 19:11, Joshua Harlow wrote:
> Fox, Kevin M wrote:
>> I'd say kube-dns and designate are very different technologies.
>>
>> kube-dns is a service discovery mechanism for kubernetes intend to provide 
>> internal k8s resolution. The fact it uses dns to implement service discovery 
>> is kind of an implementation detail, not its primary purpose. There's no 
>> need for private dns management, scaling past the size of the k8s cluster 
>> itself, etc. A much easier problem to solve at the moment.
>>
>> Designate really is a multitenant dns as a service implementation. While it 
>> can be used for service discovery, its not its primary purpose.
>>
>> I see no reason they couldn't share some common pieces, but care should be 
>> given not to just say, lets throw out one for the other, as they really are 
>> different animals.
>>
> 
> Arg, the idea wasn't meant to be that (abandon one for the other), but 
> just to investigate the larger world and maybe we have to adapt our 
> model of `multitenant dns as a service implementation` to be slightly 
> different; so what..., if it means we get to keep contributors and grow 
> a larger community (and partner with others and learn new things and 
> adopt new strategies/designs and push the limits of tech and ...) by 
> doing so then that's IMHO good.
> 

Sure - we are always open to changing out outlook.

There are however huge differences in the problem set between running
authoritative DNS, and service discovery DNS.

In service discovery, you want instant and consistant updates of
records, and is a single user environment - only one user will ever
query those DNS servers. As a result, you are not as resource
constrained when writing the DNS server, and can use slower data
storage systems (like etcd).

Authoritative DNS is accessed by multiple users, and resources per
request really do matter (this is part of the reason we do not have
a user facing DNS server as part of Designate).

The vast majority (all?) of the new DNS projects (especially in the
CNCF) are focused on Service Discovery. It is usually assumed the IaaS
underneath (AWS, Azure etc) have an auth DNS service available to use
(much like VMs are).

Because of this, I do not see a huge amount we can leverage from others,
or a huge amount we can offer others.

>> Thanks,
>> Kevin
>> ____
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Friday, February 10, 2017 9:50 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [designate] Status of the project
>>
>> On 02/10/2017 12:21 PM, Joshua Harlow wrote:
>>> Hayes, Graham wrote:
>>>> The HTML version of this is here:
>>>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>>>
>>>> I have been asked a few times recently "What is the state of the
>>>> Designate
>>>> project?", "How is Designate getting on?", and by people who know what is
>>>> happening "What are you going to do about Designate?".
>>>>
>>>> Needless to say, all of this is depressing to me, and the people that
>>>> I have
>>>> worked with for the last number of years to make Designate a truly
>>>> useful,
>>>> feature rich project.
>>>>
>>>> *TL;DR;* for this - Designate is not in a sustainable place.
>>>>
>>>> To start out - Designate has always been a small project. DNS does not
>>>> have
>>>> massive *cool* appeal - its not shiny, pretty, or something you see on
>>>> the
>>>> front page of HackerNews (unless it breaks - then oh boy do people
>>>> become DNS
>>>> experts).
>>>>
>>> Thanks for posting this, I know it was not easy to write...
>>>
>>> Knowing where this is at and the issues. It makes me wonder if it is
>>> worthwhile to start thinking about how we can start to look at 'outside
>>> the openstack' projects for DNS. I believe there is a few that are
>>> similar enough to designate (though I don't know well enough) for
>>> example things like SkyDNS (or others which I believe there are a few).
>>>
>>> Perhaps we need to start thinking outside the openstack 'box' in regards
>>> to NIH syndrome and accept the fact that we as a community may not be
>>> able to recreate the world successfully in all cases (the same could be
>>> said about things like k8s and others).
>>>
>>> If we got out of the mindset of openstack as a thing must have tightly
>>> integrated components (over 

Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 18:10, Joshua Harlow wrote:
> Jay Pipes wrote:
>> On 02/10/2017 12:21 PM, Joshua Harlow wrote:
>>> Hayes, Graham wrote:
 The HTML version of this is here:
 http://graham.hayes.ie/posts/openstack-designate-where-we-are/

 I have been asked a few times recently "What is the state of the
 Designate
 project?", "How is Designate getting on?", and by people who know
 what is
 happening "What are you going to do about Designate?".

 Needless to say, all of this is depressing to me, and the people that
 I have
 worked with for the last number of years to make Designate a truly
 useful,
 feature rich project.

 *TL;DR;* for this - Designate is not in a sustainable place.

 To start out - Designate has always been a small project. DNS does not
 have
 massive *cool* appeal - its not shiny, pretty, or something you see on
 the
 front page of HackerNews (unless it breaks - then oh boy do people
 become DNS
 experts).

>>>
>>> Thanks for posting this, I know it was not easy to write...
>>>
>>> Knowing where this is at and the issues. It makes me wonder if it is
>>> worthwhile to start thinking about how we can start to look at 'outside
>>> the openstack' projects for DNS. I believe there is a few that are
>>> similar enough to designate (though I don't know well enough) for
>>> example things like SkyDNS (or others which I believe there are a few).
>>>
>>> Perhaps we need to start thinking outside the openstack 'box' in regards
>>> to NIH syndrome and accept the fact that we as a community may not be
>>> able to recreate the world successfully in all cases (the same could be
>>> said about things like k8s and others).
>>>
>>> If we got out of the mindset of openstack as a thing must have tightly
>>> integrated components (over all else) and started thinking about how we
>>> can be much more loosely coupled (and even say integrating non-python,
>>> non-openstack projects) would that be beneficial (I think it would)?
>>
>> This is already basically what Designate *is today*.
>>
>> http://docs.openstack.org/developer/designate/support-matrix.html
>>
>> Just because something is written in Golang and uses etcd for storage
>> doesn't make it "better" or not NIH.
> 
> Agreed, do those other projects (written in golang, or etcd or other) 
> have communities that are growing; can we ensure better success (and 
> health of our own community) by partnering with them? That was the main 
> point (I don't really care what language they are written in or what 
> storage backend they use).
> 
>>
>> For the record, the equivalent to Designate in k8s land is Kube2Sky, the
>> real difference being that Designate has a whole lot more options when
>> it comes to the DNS drivers and Designate integrates with OpenStack
>> services like Keystone.
>>
> 
> That's cool, thanks; TIL.
> 
>> Also, there's more to cloud DNS services than service discovery, which
>> is what SkyDNS was written for.
> 
> Sure, it was just an example.
> 
> The point was along the lines of if a project in our community is 
> struggling and there is a similar project outside of openstack (that is 
> trying to do similar things) is not struggling; perhaps it's better to 
> partner with that other project and enhance that other project (and then 
> recommend said project as the next-generation of ${whatever_project} was 
> struggling here).

As I said in my reply - there *is* no other project.

> Said evaluation is something that we would likely have to do over time 
> as well (because as from this example, desigate was a larger group once, 
> it is now smaller).
> 
>>
>> best,
>> -jay
>>
>> __
>> 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] [designate] Status of the project

2017-02-10 Thread Joshua Harlow

Fox, Kevin M wrote:

I'd say kube-dns and designate are very different technologies.

kube-dns is a service discovery mechanism for kubernetes intend to provide 
internal k8s resolution. The fact it uses dns to implement service discovery is 
kind of an implementation detail, not its primary purpose. There's no need for 
private dns management, scaling past the size of the k8s cluster itself, etc. A 
much easier problem to solve at the moment.

Designate really is a multitenant dns as a service implementation. While it can 
be used for service discovery, its not its primary purpose.

I see no reason they couldn't share some common pieces, but care should be 
given not to just say, lets throw out one for the other, as they really are 
different animals.



Arg, the idea wasn't meant to be that (abandon one for the other), but 
just to investigate the larger world and maybe we have to adapt our 
model of `multitenant dns as a service implementation` to be slightly 
different; so what..., if it means we get to keep contributors and grow 
a larger community (and partner with others and learn new things and 
adopt new strategies/designs and push the limits of tech and ...) by 
doing so then that's IMHO good.



Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, February 10, 2017 9:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [designate] Status of the project

On 02/10/2017 12:21 PM, Joshua Harlow wrote:

Hayes, Graham wrote:

The HTML version of this is here:
http://graham.hayes.ie/posts/openstack-designate-where-we-are/

I have been asked a few times recently "What is the state of the
Designate
project?", "How is Designate getting on?", and by people who know what is
happening "What are you going to do about Designate?".

Needless to say, all of this is depressing to me, and the people that
I have
worked with for the last number of years to make Designate a truly
useful,
feature rich project.

*TL;DR;* for this - Designate is not in a sustainable place.

To start out - Designate has always been a small project. DNS does not
have
massive *cool* appeal - its not shiny, pretty, or something you see on
the
front page of HackerNews (unless it breaks - then oh boy do people
become DNS
experts).


Thanks for posting this, I know it was not easy to write...

Knowing where this is at and the issues. It makes me wonder if it is
worthwhile to start thinking about how we can start to look at 'outside
the openstack' projects for DNS. I believe there is a few that are
similar enough to designate (though I don't know well enough) for
example things like SkyDNS (or others which I believe there are a few).

Perhaps we need to start thinking outside the openstack 'box' in regards
to NIH syndrome and accept the fact that we as a community may not be
able to recreate the world successfully in all cases (the same could be
said about things like k8s and others).

If we got out of the mindset of openstack as a thing must have tightly
integrated components (over all else) and started thinking about how we
can be much more loosely coupled (and even say integrating non-python,
non-openstack projects) would that be beneficial (I think it would)?


This is already basically what Designate *is today*.

http://docs.openstack.org/developer/designate/support-matrix.html

Just because something is written in Golang and uses etcd for storage
doesn't make it "better" or not NIH.

For the record, the equivalent to Designate in k8s land is Kube2Sky, the
real difference being that Designate has a whole lot more options when
it comes to the DNS drivers and Designate integrates with OpenStack
services like Keystone.

Also, there's more to cloud DNS services than service discovery, which
is what SkyDNS was written for.

best,
-jay

__
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] [designate] Status of the project

2017-02-10 Thread Fox, Kevin M
I'd say kube-dns and designate are very different technologies.

kube-dns is a service discovery mechanism for kubernetes intend to provide 
internal k8s resolution. The fact it uses dns to implement service discovery is 
kind of an implementation detail, not its primary purpose. There's no need for 
private dns management, scaling past the size of the k8s cluster itself, etc. A 
much easier problem to solve at the moment.

Designate really is a multitenant dns as a service implementation. While it can 
be used for service discovery, its not its primary purpose.

I see no reason they couldn't share some common pieces, but care should be 
given not to just say, lets throw out one for the other, as they really are 
different animals.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, February 10, 2017 9:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [designate] Status of the project

On 02/10/2017 12:21 PM, Joshua Harlow wrote:
> Hayes, Graham wrote:
>> The HTML version of this is here:
>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>
>> I have been asked a few times recently "What is the state of the
>> Designate
>> project?", "How is Designate getting on?", and by people who know what is
>> happening "What are you going to do about Designate?".
>>
>> Needless to say, all of this is depressing to me, and the people that
>> I have
>> worked with for the last number of years to make Designate a truly
>> useful,
>> feature rich project.
>>
>> *TL;DR;* for this - Designate is not in a sustainable place.
>>
>> To start out - Designate has always been a small project. DNS does not
>> have
>> massive *cool* appeal - its not shiny, pretty, or something you see on
>> the
>> front page of HackerNews (unless it breaks - then oh boy do people
>> become DNS
>> experts).
>>
>
> Thanks for posting this, I know it was not easy to write...
>
> Knowing where this is at and the issues. It makes me wonder if it is
> worthwhile to start thinking about how we can start to look at 'outside
> the openstack' projects for DNS. I believe there is a few that are
> similar enough to designate (though I don't know well enough) for
> example things like SkyDNS (or others which I believe there are a few).
>
> Perhaps we need to start thinking outside the openstack 'box' in regards
> to NIH syndrome and accept the fact that we as a community may not be
> able to recreate the world successfully in all cases (the same could be
> said about things like k8s and others).
>
> If we got out of the mindset of openstack as a thing must have tightly
> integrated components (over all else) and started thinking about how we
> can be much more loosely coupled (and even say integrating non-python,
> non-openstack projects) would that be beneficial (I think it would)?

This is already basically what Designate *is today*.

http://docs.openstack.org/developer/designate/support-matrix.html

Just because something is written in Golang and uses etcd for storage
doesn't make it "better" or not NIH.

For the record, the equivalent to Designate in k8s land is Kube2Sky, the
real difference being that Designate has a whole lot more options when
it comes to the DNS drivers and Designate integrates with OpenStack
services like Keystone.

Also, there's more to cloud DNS services than service discovery, which
is what SkyDNS was written for.

best,
-jay

__
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] Status of the project

2017-02-10 Thread Joshua Harlow

Jay Pipes wrote:

On 02/10/2017 12:21 PM, Joshua Harlow wrote:

Hayes, Graham wrote:

The HTML version of this is here:
http://graham.hayes.ie/posts/openstack-designate-where-we-are/

I have been asked a few times recently "What is the state of the
Designate
project?", "How is Designate getting on?", and by people who know
what is
happening "What are you going to do about Designate?".

Needless to say, all of this is depressing to me, and the people that
I have
worked with for the last number of years to make Designate a truly
useful,
feature rich project.

*TL;DR;* for this - Designate is not in a sustainable place.

To start out - Designate has always been a small project. DNS does not
have
massive *cool* appeal - its not shiny, pretty, or something you see on
the
front page of HackerNews (unless it breaks - then oh boy do people
become DNS
experts).



Thanks for posting this, I know it was not easy to write...

Knowing where this is at and the issues. It makes me wonder if it is
worthwhile to start thinking about how we can start to look at 'outside
the openstack' projects for DNS. I believe there is a few that are
similar enough to designate (though I don't know well enough) for
example things like SkyDNS (or others which I believe there are a few).

Perhaps we need to start thinking outside the openstack 'box' in regards
to NIH syndrome and accept the fact that we as a community may not be
able to recreate the world successfully in all cases (the same could be
said about things like k8s and others).

If we got out of the mindset of openstack as a thing must have tightly
integrated components (over all else) and started thinking about how we
can be much more loosely coupled (and even say integrating non-python,
non-openstack projects) would that be beneficial (I think it would)?


This is already basically what Designate *is today*.

http://docs.openstack.org/developer/designate/support-matrix.html

Just because something is written in Golang and uses etcd for storage
doesn't make it "better" or not NIH.


Agreed, do those other projects (written in golang, or etcd or other) 
have communities that are growing; can we ensure better success (and 
health of our own community) by partnering with them? That was the main 
point (I don't really care what language they are written in or what 
storage backend they use).




For the record, the equivalent to Designate in k8s land is Kube2Sky, the
real difference being that Designate has a whole lot more options when
it comes to the DNS drivers and Designate integrates with OpenStack
services like Keystone.



That's cool, thanks; TIL.


Also, there's more to cloud DNS services than service discovery, which
is what SkyDNS was written for.


Sure, it was just an example.

The point was along the lines of if a project in our community is 
struggling and there is a similar project outside of openstack (that is 
trying to do similar things) is not struggling; perhaps it's better to 
partner with that other project and enhance that other project (and then 
recommend said project as the next-generation of ${whatever_project} was 
struggling here).


Said evaluation is something that we would likely have to do over time 
as well (because as from this example, desigate was a larger group once, 
it is now smaller).




best,
-jay

__
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] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 16:39, Alexandra Settle wrote:
> Sorry, I’m top posting to this reply because Outlook is a terrible inline 
> poster.
> 
> Hey Designaters! 
> 
> Have you tried pinging the docs team? (ie: me – Hello! I’m the docs PTL)

Hi - We have in the past, and did not get very far. I know things are
now changing, so expect me to ping you over the next few weeks :)

> Over the last few cycles our team has been able to step in and help with 
> formatting, writing, and organizing documentation. Helping small projects 
> (like OpenStack-Ansible) to fix several of the issues you noted below 
> (install, operations, dev docs). During the Newton cycle I was able to help 
> the OSA team organize their dev docs: 
> http://docs.openstack.org/developer/openstack-ansible/developer-docs/index.html,
>  and as a team we created the Deploy Guide 
> http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/. And 
> for Ocata, we have been working heavily on their operations content: 
> http://docs.openstack.org/developer/openstack-ansible/draft-operations-guide/index.html
>  
> 
> Technical writers do not often have the expertise to provide SME knowledge 
> (that’s your job), but we are experts when it concerns ensuring documentation 
> is in the right place to help new users. And we are the guardians of the 
> Operations Guide.
> 
> I know your conversation is much larger than just fixing documentation, but 
> if we can help, please shout out :) 

Thanks for reaching out, I will definitely shout if need it.

- Graham

> On 2/10/17, 3:53 PM, "Hayes, Graham"  wrote:
> 
> On 10/02/17 02:40, Jay Pipes wrote:
> > On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> > 
> > 
> >> Where too now then?
> >> ===
> >>
> >> Well, this is where I call out to people who actually use the project -
> >> don't
> >> jump ship and use something else because of the picture I have painted.
> >> We are
> >> a dedicated team, how cares about the project. We just need some help.
> >>
> >> I know there are large telcos who use Designate. I am sure there is 
> tooling,
> >> or docs build up in these companies that could be very useful to the
> >> project.
> >>
> >> Nearly every commercial OpenStack distro has Designate. Some have had 
> it
> >> since
> >> the beginning. Again, developers, docs, tooling, testers, anything and
> >> everything is welcome. We don't need a massive amount of resources - we
> >> are a
> >> small ish, stable, project.
> >>
> >> We need developers with upstream time allocated, and the budget to go 
> to
> >> events
> >> like the PTG - for cross project work, and internal designate road map,
> >> these
> >> events form the core of how we work.
> >>
> >> We also need help from cross project teams - the work done by them is
> >> brilliant
> >> but it can be hard for smaller projects to consume. We have had a lot 
> of
> >> progress since the `Leveller Playing Field`_ debate, but a lot of work 
> is
> >> still optimised for the larger teams who get direct support, or well
> >> resourced
> >> teams who can dedicate people to the implementation of plugins / code.
> >>
> >> As someone I was talking to recently said - AWS is not winning public 
> cloud
> >> because of commodity compute (that does help - a lot), but because of 
> the
> >> added services that make using the cloud, well, cloud like. OpenStack
> >> needs to
> >> decide that either it is just compute, or if it wants the eco-system. 
> [5]_
> >> Designate is far from alone in this.
> > 
> > 
> > 
> > Graham, thank you for the heartfelt post. I may not agree with all your 
> > points, but I know you're coming from the right place and truly want to 
> > see Designate (and OpenStack in general) succeed.
> 
> Thanks for reading - it ended up longer than expected.
> 
> > Your point about smaller projects finding it more difficult to 
> "consume" 
> > help from cross-project teams is an interesting one. When the big tent 
> > was being discussed, I remember the TC specifically discussing a change 
> > for cross-project team focus: moving from a "we do this work for you" 
> > role to a "we help you do this work for yourself" role. You're correct 
> > that the increase in OpenStack projects meant that the cross-project 
> > teams simply would not be able to continue to be a service to other 
> > teams. This was definitely predicted during the big tent discussions.
> 
> I remember the same things being discussed. However, that is not what
> happened, at least not immediately, and it can be very hard to
> motivate yourself to work on things when everytime you ask for help
> you get nothing, other than a link to the docs page you have read
> a 100 times.
> 
> > If 

Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Jay Pipes

On 02/10/2017 12:21 PM, Joshua Harlow wrote:

Hayes, Graham wrote:

The HTML version of this is here:
http://graham.hayes.ie/posts/openstack-designate-where-we-are/

I have been asked a few times recently "What is the state of the
Designate
project?", "How is Designate getting on?", and by people who know what is
happening "What are you going to do about Designate?".

Needless to say, all of this is depressing to me, and the people that
I have
worked with for the last number of years to make Designate a truly
useful,
feature rich project.

*TL;DR;* for this - Designate is not in a sustainable place.

To start out - Designate has always been a small project. DNS does not
have
massive *cool* appeal - its not shiny, pretty, or something you see on
the
front page of HackerNews (unless it breaks - then oh boy do people
become DNS
experts).



Thanks for posting this, I know it was not easy to write...

Knowing where this is at and the issues. It makes me wonder if it is
worthwhile to start thinking about how we can start to look at 'outside
the openstack' projects for DNS. I believe there is a few that are
similar enough to designate (though I don't know well enough) for
example things like SkyDNS (or others which I believe there are a few).

Perhaps we need to start thinking outside the openstack 'box' in regards
to NIH syndrome and accept the fact that we as a community may not be
able to recreate the world successfully in all cases (the same could be
said about things like k8s and others).

If we got out of the mindset of openstack as a thing must have tightly
integrated components (over all else) and started thinking about how we
can be much more loosely coupled (and even say integrating non-python,
non-openstack projects) would that be beneficial (I think it would)?


This is already basically what Designate *is today*.

http://docs.openstack.org/developer/designate/support-matrix.html

Just because something is written in Golang and uses etcd for storage 
doesn't make it "better" or not NIH.


For the record, the equivalent to Designate in k8s land is Kube2Sky, the 
real difference being that Designate has a whole lot more options when 
it comes to the DNS drivers and Designate integrates with OpenStack 
services like Keystone.


Also, there's more to cloud DNS services than service discovery, which 
is what SkyDNS was written for.


best,
-jay

__
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] Status of the project

2017-02-10 Thread Mike Spreitzer
Joshua Harlow  wrote on 02/10/2017 12:21:08 PM:

> Knowing where this is at and the issues. It makes me wonder if it is 
> worthwhile to start thinking about how we can start to look at 'outside 
> the openstack' projects for DNS. I believe there is a few that are 
> similar enough to designate (though I don't know well enough) for 
> example things like SkyDNS (or others which I believe there are a few).
> 
> Perhaps we need to start thinking outside the openstack 'box' in regards 

> to NIH syndrome and accept the fact that we as a community may not be 
> able to recreate the world successfully in all cases (the same could be 
> said about things like k8s and others).
> 
> If we got out of the mindset of openstack as a thing must have tightly 
> integrated components (over all else) and started thinking about how we 
> can be much more loosely coupled (and even say integrating non-python, 
> non-openstack projects) would that be beneficial (I think it would)?

I think you might be on to something.  The Kubernetes community seems to 
be thinking about an external DNS service too.  I see 
https://github.com/kubernetes-incubator/external-dns was just created, but 
do not know anything more about it.

Regards,
Mike



__
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] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 17:24, Joshua Harlow wrote:
> Hayes, Graham wrote:
>> The HTML version of this is here:
>> http://graham.hayes.ie/posts/openstack-designate-where-we-are/
>>
>> I have been asked a few times recently "What is the state of the Designate
>> project?", "How is Designate getting on?", and by people who know what is
>> happening "What are you going to do about Designate?".
>>
>> Needless to say, all of this is depressing to me, and the people that I have
>> worked with for the last number of years to make Designate a truly useful,
>> feature rich project.
>>
>> *TL;DR;* for this - Designate is not in a sustainable place.
>>
>> To start out - Designate has always been a small project. DNS does not have
>> massive *cool* appeal - its not shiny, pretty, or something you see on the
>> front page of HackerNews (unless it breaks - then oh boy do people
>> become DNS
>> experts).
>>
> 
> Thanks for posting this, I know it was not easy to write...
> 
> Knowing where this is at and the issues. It makes me wonder if it is 
> worthwhile to start thinking about how we can start to look at 'outside 
> the openstack' projects for DNS. I believe there is a few that are 
> similar enough to designate (though I don't know well enough) for 
> example things like SkyDNS (or others which I believe there are a few).

SkyDNS is a mechanism for service discovery, not a DNS API. In reality
there is very few (if any actually - I am struggling to think of even
one) multi tenant DNS management APIs.

The use of DNS in clouds is more than just having an cli to call to
update DNS entries. Integration's between the cloud components are what
make it useful - Heat / CloudFormation / Terraform resources that can
read info from network ports, floating IPs, load balancers, etc is
where the value comes in.

Combined with the integration in neutron that we (finally) merged
recently, I think we have a compelling case to keep Designate.

Ask most AWS users how much they use route53 - this is what we should
be aiming for with Designate.

> Perhaps we need to start thinking outside the openstack 'box' in regards 
> to NIH syndrome and accept the fact that we as a community may not be 
> able to recreate the world successfully in all cases (the same could be 
> said about things like k8s and others).

sure - this comes back to be "base set" of services that the Arch WG
were looking at. however, having coupled services can be useful, and
having a guaranteed API across clouds (one of our goals afaik) for
basic services (which I would count DNS as) is a big deal.

> If we got out of the mindset of openstack as a thing must have tightly 
> integrated components (over all else) and started thinking about how we 
> can be much more loosely coupled (and even say integrating non-python, 
> non-openstack projects) would that be beneficial (I think it would)?
> 
> -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
> 


__
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] Status of the project

2017-02-10 Thread Joshua Harlow

Hayes, Graham wrote:

The HTML version of this is here:
http://graham.hayes.ie/posts/openstack-designate-where-we-are/

I have been asked a few times recently "What is the state of the Designate
project?", "How is Designate getting on?", and by people who know what is
happening "What are you going to do about Designate?".

Needless to say, all of this is depressing to me, and the people that I have
worked with for the last number of years to make Designate a truly useful,
feature rich project.

*TL;DR;* for this - Designate is not in a sustainable place.

To start out - Designate has always been a small project. DNS does not have
massive *cool* appeal - its not shiny, pretty, or something you see on the
front page of HackerNews (unless it breaks - then oh boy do people
become DNS
experts).



Thanks for posting this, I know it was not easy to write...

Knowing where this is at and the issues. It makes me wonder if it is 
worthwhile to start thinking about how we can start to look at 'outside 
the openstack' projects for DNS. I believe there is a few that are 
similar enough to designate (though I don't know well enough) for 
example things like SkyDNS (or others which I believe there are a few).


Perhaps we need to start thinking outside the openstack 'box' in regards 
to NIH syndrome and accept the fact that we as a community may not be 
able to recreate the world successfully in all cases (the same could be 
said about things like k8s and others).


If we got out of the mindset of openstack as a thing must have tightly 
integrated components (over all else) and started thinking about how we 
can be much more loosely coupled (and even say integrating non-python, 
non-openstack projects) would that be beneficial (I think it would)?


-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] [designate] Status of the project

2017-02-10 Thread Alexandra Settle
Sorry, I’m top posting to this reply because Outlook is a terrible inline 
poster.

Hey Designaters! 

Have you tried pinging the docs team? (ie: me – Hello! I’m the docs PTL)

Over the last few cycles our team has been able to step in and help with 
formatting, writing, and organizing documentation. Helping small projects (like 
OpenStack-Ansible) to fix several of the issues you noted below (install, 
operations, dev docs). During the Newton cycle I was able to help the OSA team 
organize their dev docs: 
http://docs.openstack.org/developer/openstack-ansible/developer-docs/index.html,
 and as a team we created the Deploy Guide 
http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/. And 
for Ocata, we have been working heavily on their operations content: 
http://docs.openstack.org/developer/openstack-ansible/draft-operations-guide/index.html
 

Technical writers do not often have the expertise to provide SME knowledge 
(that’s your job), but we are experts when it concerns ensuring documentation 
is in the right place to help new users. And we are the guardians of the 
Operations Guide.

I know your conversation is much larger than just fixing documentation, but if 
we can help, please shout out :) 

On 2/10/17, 3:53 PM, "Hayes, Graham"  wrote:

On 10/02/17 02:40, Jay Pipes wrote:
> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> 
> 
>> Where too now then?
>> ===
>>
>> Well, this is where I call out to people who actually use the project -
>> don't
>> jump ship and use something else because of the picture I have painted.
>> We are
>> a dedicated team, how cares about the project. We just need some help.
>>
>> I know there are large telcos who use Designate. I am sure there is 
tooling,
>> or docs build up in these companies that could be very useful to the
>> project.
>>
>> Nearly every commercial OpenStack distro has Designate. Some have had it
>> since
>> the beginning. Again, developers, docs, tooling, testers, anything and
>> everything is welcome. We don't need a massive amount of resources - we
>> are a
>> small ish, stable, project.
>>
>> We need developers with upstream time allocated, and the budget to go to
>> events
>> like the PTG - for cross project work, and internal designate road map,
>> these
>> events form the core of how we work.
>>
>> We also need help from cross project teams - the work done by them is
>> brilliant
>> but it can be hard for smaller projects to consume. We have had a lot of
>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>> still optimised for the larger teams who get direct support, or well
>> resourced
>> teams who can dedicate people to the implementation of plugins / code.
>>
>> As someone I was talking to recently said - AWS is not winning public 
cloud
>> because of commodity compute (that does help - a lot), but because of the
>> added services that make using the cloud, well, cloud like. OpenStack
>> needs to
>> decide that either it is just compute, or if it wants the eco-system. 
[5]_
>> Designate is far from alone in this.
> 
> 
> 
> Graham, thank you for the heartfelt post. I may not agree with all your 
> points, but I know you're coming from the right place and truly want to 
> see Designate (and OpenStack in general) succeed.

Thanks for reading - it ended up longer than expected.

> Your point about smaller projects finding it more difficult to "consume" 
> help from cross-project teams is an interesting one. When the big tent 
> was being discussed, I remember the TC specifically discussing a change 
> for cross-project team focus: moving from a "we do this work for you" 
> role to a "we help you do this work for yourself" role. You're correct 
> that the increase in OpenStack projects meant that the cross-project 
> teams simply would not be able to continue to be a service to other 
> teams. This was definitely predicted during the big tent discussions.

I remember the same things being discussed. However, that is not what
happened, at least not immediately, and it can be very hard to
motivate yourself to work on things when everytime you ask for help
you get nothing, other than a link to the docs page you have read
a 100 times.

> If I had one piece of advice to give Designate, it would be to 
> prioritize getting documentation (both installation as well as dev-ref 
> and operational docs) in good shape. I know writing docs sucks, but docs 
> are a springboard for users and contributors alike and can have a 
> multiplying effect that's difficult to overstate. Getting those install 
> and developer docs started would enable the cross-project docs team to 
> guide 

Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 15:48, Doug Hellmann wrote:
> Excerpts from Jay Pipes's message of 2017-02-09 21:33:03 -0500:
>> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
>> 
>>
>>> Where too now then?
>>> ===
>>>
>>> Well, this is where I call out to people who actually use the project -
>>> don't
>>> jump ship and use something else because of the picture I have painted.
>>> We are
>>> a dedicated team, how cares about the project. We just need some help.
>>>
>>> I know there are large telcos who use Designate. I am sure there is tooling,
>>> or docs build up in these companies that could be very useful to the
>>> project.
>>>
>>> Nearly every commercial OpenStack distro has Designate. Some have had it
>>> since
>>> the beginning. Again, developers, docs, tooling, testers, anything and
>>> everything is welcome. We don't need a massive amount of resources - we
>>> are a
>>> small ish, stable, project.
>>>
>>> We need developers with upstream time allocated, and the budget to go to
>>> events
>>> like the PTG - for cross project work, and internal designate road map,
>>> these
>>> events form the core of how we work.
>>>
>>> We also need help from cross project teams - the work done by them is
>>> brilliant
>>> but it can be hard for smaller projects to consume. We have had a lot of
>>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>>> still optimised for the larger teams who get direct support, or well
>>> resourced
>>> teams who can dedicate people to the implementation of plugins / code.
>>>
>>> As someone I was talking to recently said - AWS is not winning public cloud
>>> because of commodity compute (that does help - a lot), but because of the
>>> added services that make using the cloud, well, cloud like. OpenStack
>>> needs to
>>> decide that either it is just compute, or if it wants the eco-system. [5]_
>>> Designate is far from alone in this.
>>
>> 
>>
>> Graham, thank you for the heartfelt post. I may not agree with all your 
>> points, but I know you're coming from the right place and truly want to 
>> see Designate (and OpenStack in general) succeed.
>>
>> Your point about smaller projects finding it more difficult to "consume" 
>> help from cross-project teams is an interesting one. When the big tent 
>> was being discussed, I remember the TC specifically discussing a change 
>> for cross-project team focus: moving from a "we do this work for you" 
>> role to a "we help you do this work for yourself" role. You're correct 
>> that the increase in OpenStack projects meant that the cross-project 
>> teams simply would not be able to continue to be a service to other 
>> teams. This was definitely predicted during the big tent discussions.
>>
>> If I had one piece of advice to give Designate, it would be to 
>> prioritize getting documentation (both installation as well as dev-ref 
>> and operational docs) in good shape. I know writing docs sucks, but docs 
>> are a springboard for users and contributors alike and can have a 
>> multiplying effect that's difficult to overstate. Getting those install 
>> and developer docs started would enable the cross-project docs team to 
>> guide Designate contributors in enhancing and cleaning up the docs and 
>> putting some polish on 'em. Your idea above that maybe some users 
>> already wrote some docs is a good one. Maybe reach out personally to 
>> those telcos and see if they can dig something up that can be the basis 
>> for upstream docs.
>>
>> Best,
>> -jay
>>
> 
> Thank you for bringing this into the open, Graham.
> 
> I think we have several projects that would benefit by transitioning
> from relying solely on vendor contributions to building up the
> deployer/user contributor base. That's a relatively new approach
> for some parts of the OpenStack community, but it's common elsewhere
> in open source projects. The shift is likely to mean some changes
> in the way we organize ourselves, because it may not be reasonable
> to assume user-contributors have large amounts of time to focus on
> long review cycles, traveling to sprints, or the other intensive
> activities that are part of our current routine. (That's not to say
> the Designate team has introduced any of those issues, of course.
> We need to be thinking about removing obstacles for contributors
> across the entire community.)

Yes - definitely. We try to be good about review cycles (with the amount
we get, it is not that difficult for us to be good about bug triage, and
review triage), but I agree - how we work does make things difficult
for user contributors to become key contributors to a project.

Even for people who want to contribute as a hobby, the time and level
of funding required is quite high.

Thanks,

Graham

> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [designate] Status of the project

2017-02-10 Thread Hayes, Graham
On 10/02/17 02:40, Jay Pipes wrote:
> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> 
> 
>> Where too now then?
>> ===
>>
>> Well, this is where I call out to people who actually use the project -
>> don't
>> jump ship and use something else because of the picture I have painted.
>> We are
>> a dedicated team, how cares about the project. We just need some help.
>>
>> I know there are large telcos who use Designate. I am sure there is tooling,
>> or docs build up in these companies that could be very useful to the
>> project.
>>
>> Nearly every commercial OpenStack distro has Designate. Some have had it
>> since
>> the beginning. Again, developers, docs, tooling, testers, anything and
>> everything is welcome. We don't need a massive amount of resources - we
>> are a
>> small ish, stable, project.
>>
>> We need developers with upstream time allocated, and the budget to go to
>> events
>> like the PTG - for cross project work, and internal designate road map,
>> these
>> events form the core of how we work.
>>
>> We also need help from cross project teams - the work done by them is
>> brilliant
>> but it can be hard for smaller projects to consume. We have had a lot of
>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>> still optimised for the larger teams who get direct support, or well
>> resourced
>> teams who can dedicate people to the implementation of plugins / code.
>>
>> As someone I was talking to recently said - AWS is not winning public cloud
>> because of commodity compute (that does help - a lot), but because of the
>> added services that make using the cloud, well, cloud like. OpenStack
>> needs to
>> decide that either it is just compute, or if it wants the eco-system. [5]_
>> Designate is far from alone in this.
> 
> 
> 
> Graham, thank you for the heartfelt post. I may not agree with all your 
> points, but I know you're coming from the right place and truly want to 
> see Designate (and OpenStack in general) succeed.

Thanks for reading - it ended up longer than expected.

> Your point about smaller projects finding it more difficult to "consume" 
> help from cross-project teams is an interesting one. When the big tent 
> was being discussed, I remember the TC specifically discussing a change 
> for cross-project team focus: moving from a "we do this work for you" 
> role to a "we help you do this work for yourself" role. You're correct 
> that the increase in OpenStack projects meant that the cross-project 
> teams simply would not be able to continue to be a service to other 
> teams. This was definitely predicted during the big tent discussions.

I remember the same things being discussed. However, that is not what
happened, at least not immediately, and it can be very hard to
motivate yourself to work on things when everytime you ask for help
you get nothing, other than a link to the docs page you have read
a 100 times.

> If I had one piece of advice to give Designate, it would be to 
> prioritize getting documentation (both installation as well as dev-ref 
> and operational docs) in good shape. I know writing docs sucks, but docs 
> are a springboard for users and contributors alike and can have a 
> multiplying effect that's difficult to overstate. Getting those install 
> and developer docs started would enable the cross-project docs team to 
> guide Designate contributors in enhancing and cleaning up the docs and 
> putting some polish on 'em. Your idea above that maybe some users 
> already wrote some docs is a good one. Maybe reach out personally to 
> those telcos and see if they can dig something up that can be the basis 
> for upstream docs.

Yeah, writing docs is hard to do right, and honestly, we have been
trying to just keep up with bugs recently.

The problem for us is, where do things like operational docs go?
There is an ops guide, but it is very hard to see where we could
put content. I am also a firm believer that
docs.openstack.org/developer/ is *not* the place for
end user / ops / etc documentation - its why our docs are so
messy right now.

I have pinged a few people for docs, and am waiting for responses.

> Best,
> -jay
> 
> 
> 
> __
> 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] Status of the project

2017-02-10 Thread Doug Hellmann
Excerpts from Jay Pipes's message of 2017-02-09 21:33:03 -0500:
> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> 
> 
> > Where too now then?
> > ===
> >
> > Well, this is where I call out to people who actually use the project -
> > don't
> > jump ship and use something else because of the picture I have painted.
> > We are
> > a dedicated team, how cares about the project. We just need some help.
> >
> > I know there are large telcos who use Designate. I am sure there is tooling,
> > or docs build up in these companies that could be very useful to the
> > project.
> >
> > Nearly every commercial OpenStack distro has Designate. Some have had it
> > since
> > the beginning. Again, developers, docs, tooling, testers, anything and
> > everything is welcome. We don't need a massive amount of resources - we
> > are a
> > small ish, stable, project.
> >
> > We need developers with upstream time allocated, and the budget to go to
> > events
> > like the PTG - for cross project work, and internal designate road map,
> > these
> > events form the core of how we work.
> >
> > We also need help from cross project teams - the work done by them is
> > brilliant
> > but it can be hard for smaller projects to consume. We have had a lot of
> > progress since the `Leveller Playing Field`_ debate, but a lot of work is
> > still optimised for the larger teams who get direct support, or well
> > resourced
> > teams who can dedicate people to the implementation of plugins / code.
> >
> > As someone I was talking to recently said - AWS is not winning public cloud
> > because of commodity compute (that does help - a lot), but because of the
> > added services that make using the cloud, well, cloud like. OpenStack
> > needs to
> > decide that either it is just compute, or if it wants the eco-system. [5]_
> > Designate is far from alone in this.
> 
> 
> 
> Graham, thank you for the heartfelt post. I may not agree with all your 
> points, but I know you're coming from the right place and truly want to 
> see Designate (and OpenStack in general) succeed.
> 
> Your point about smaller projects finding it more difficult to "consume" 
> help from cross-project teams is an interesting one. When the big tent 
> was being discussed, I remember the TC specifically discussing a change 
> for cross-project team focus: moving from a "we do this work for you" 
> role to a "we help you do this work for yourself" role. You're correct 
> that the increase in OpenStack projects meant that the cross-project 
> teams simply would not be able to continue to be a service to other 
> teams. This was definitely predicted during the big tent discussions.
> 
> If I had one piece of advice to give Designate, it would be to 
> prioritize getting documentation (both installation as well as dev-ref 
> and operational docs) in good shape. I know writing docs sucks, but docs 
> are a springboard for users and contributors alike and can have a 
> multiplying effect that's difficult to overstate. Getting those install 
> and developer docs started would enable the cross-project docs team to 
> guide Designate contributors in enhancing and cleaning up the docs and 
> putting some polish on 'em. Your idea above that maybe some users 
> already wrote some docs is a good one. Maybe reach out personally to 
> those telcos and see if they can dig something up that can be the basis 
> for upstream docs.
> 
> Best,
> -jay
> 

Thank you for bringing this into the open, Graham.

I think we have several projects that would benefit by transitioning
from relying solely on vendor contributions to building up the
deployer/user contributor base. That's a relatively new approach
for some parts of the OpenStack community, but it's common elsewhere
in open source projects. The shift is likely to mean some changes
in the way we organize ourselves, because it may not be reasonable
to assume user-contributors have large amounts of time to focus on
long review cycles, traveling to sprints, or the other intensive
activities that are part of our current routine. (That's not to say
the Designate team has introduced any of those issues, of course.
We need to be thinking about removing obstacles for contributors
across the entire community.)

Doug

__
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] Status of the project

2017-02-09 Thread Jay Pipes

On 02/09/2017 02:19 PM, Hayes, Graham wrote:



Where too now then?
===

Well, this is where I call out to people who actually use the project -
don't
jump ship and use something else because of the picture I have painted.
We are
a dedicated team, how cares about the project. We just need some help.

I know there are large telcos who use Designate. I am sure there is tooling,
or docs build up in these companies that could be very useful to the
project.

Nearly every commercial OpenStack distro has Designate. Some have had it
since
the beginning. Again, developers, docs, tooling, testers, anything and
everything is welcome. We don't need a massive amount of resources - we
are a
small ish, stable, project.

We need developers with upstream time allocated, and the budget to go to
events
like the PTG - for cross project work, and internal designate road map,
these
events form the core of how we work.

We also need help from cross project teams - the work done by them is
brilliant
but it can be hard for smaller projects to consume. We have had a lot of
progress since the `Leveller Playing Field`_ debate, but a lot of work is
still optimised for the larger teams who get direct support, or well
resourced
teams who can dedicate people to the implementation of plugins / code.

As someone I was talking to recently said - AWS is not winning public cloud
because of commodity compute (that does help - a lot), but because of the
added services that make using the cloud, well, cloud like. OpenStack
needs to
decide that either it is just compute, or if it wants the eco-system. [5]_
Designate is far from alone in this.




Graham, thank you for the heartfelt post. I may not agree with all your 
points, but I know you're coming from the right place and truly want to 
see Designate (and OpenStack in general) succeed.


Your point about smaller projects finding it more difficult to "consume" 
help from cross-project teams is an interesting one. When the big tent 
was being discussed, I remember the TC specifically discussing a change 
for cross-project team focus: moving from a "we do this work for you" 
role to a "we help you do this work for yourself" role. You're correct 
that the increase in OpenStack projects meant that the cross-project 
teams simply would not be able to continue to be a service to other 
teams. This was definitely predicted during the big tent discussions.


If I had one piece of advice to give Designate, it would be to 
prioritize getting documentation (both installation as well as dev-ref 
and operational docs) in good shape. I know writing docs sucks, but docs 
are a springboard for users and contributors alike and can have a 
multiplying effect that's difficult to overstate. Getting those install 
and developer docs started would enable the cross-project docs team to 
guide Designate contributors in enhancing and cleaning up the docs and 
putting some polish on 'em. Your idea above that maybe some users 
already wrote some docs is a good one. Maybe reach out personally to 
those telcos and see if they can dig something up that can be the basis 
for upstream docs.


Best,
-jay



__
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