Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jay Pipes]

On 07/14/2017 06:01 PM, Samuel Cassiba wrote:

Chiming in from the believed-to-be-dead Chef project, I work on it because it 
scratches my itch. I served as PTL because it did and does scratch my itch. 
Working on it in any capacity that moves things forward continues to scratch 
that itch. We have less of a technical problem, not to downplay our tech debt, 
as we’re still pushing patches and shuffling reviews. However, we have a huge 
perception problem and equally large marketing problem, which is apparently an 
unwritten side job of being a PTL. We didn’t get that memo until the Big Tent 
was deemed too smothering. The fun part about being a PTL with effectively no 
team is that, when you or your counterpart isn’t actively marketing and 
spending more time making noise than working, people call you dead to your 
face. Even when you spend the time and money to go to marketing events.


Over the past year or so, many industry pundits, former developers and 
IT folks have said that OpenStack is dead technology or that the 
OpenStack community and project's best days are behind it. I've 
personally suffered from depression [1] due to these naysayer's remarks. 
My "dead" remarks about the OpenStack Chef contribution staleness were 
categorically deaf to my own laments regarding the cause of my 
depressing thoughts.


Sam, I'm sorry that I said in the Fuel big tent thread that OpenStack 
Chef was effectively dead. While what I meant was that OpenStack Chef 
has very few contributors/maintainers, using the word "dead" was both 
impolite and emotionally insensitive. Please accept my apologies.


While I don't believe OpenStack is dead technology, I do recognize it's 
no longer cool. And that's fine with me. Outside of Silly Valley, 
coolness actually isn't all that attractive, I've learned. And so we 
should take heart that, as Tim Bell so eloquently put it [2]: "The cool 
things are the applications you enable."


Certainly words to remember.

Regards,
-jay

[1] https://twitter.com/jaypipes/status/883011672851570688
[2] https://twitter.com/noggin143/status/883025921095208960

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Samuel Cassiba]

On Jul 14, 2017, at 14:10, Ed Leafe  wrote:
> 
> On Jul 14, 2017, at 2:17 PM, Zane Bitter  wrote:
> 
>> * The pool of OpenStack developers is a fixed resource, and if we make it 
>> clear that some projects are unwelcome then their developers will be 
>> reassigned to 'core' projects in a completely zero-sum process. (Nnope.)
> 
> Yeah, I’ve heard this many times, and always shake my head. If I want to work 
> on X, and X is not in OpenStack governance, I’m going to work on that anyway 
> because I need it. Or maybe on a similar project. I’m going to scratch my 
> itch.
> 
>> * While code like e.g. the Nova scheduler might be so complicated today that 
>> even the experts routinely complain about its terrible design,[1] if only we 
>> could add dozens more cooks (see above) it would definitely get much simpler 
>> and easier to maintain. (Bwahahahahahahaha.)
> 
> No, they need to appoint me as the Scheduler Overlord with the power to smite 
> all those who propose complicated code!
> 
>> * Once we make it clear to users that under no circumstances will we ever 
>> e.g. provide them with notifications about when a server has failed, ways to 
>> orchestrate a replacement, and an API to update DNS to point to the new one, 
>> then they will finally stop demanding bloat-inducing VMWare/oVirt-style 
>> features that enable them to treat cloud servers like pets. (I. don't. even.)
> 
> Again, itches will be scratched. What I think is more important is a 
> marketing issue, not a technical one. When I think of what it means to be a 
> “core” project, I think of things that people looking to “get cloudy” would 
> likely want. It isn’t until you start using a cloud that the additional 
> projects you mention become important. So simplifying what is presented to 
> the cloud market is a good thing, as it won’t confuse people as to what 
> OpenStack is. But that doesn’t require any of the other projects be stopped 
> or in any way discouraged.
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> __
> 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


Chiming in from the believed-to-be-dead Chef project, I work on it because it 
scratches my itch. I served as PTL because it did and does scratch my itch. 
Working on it in any capacity that moves things forward continues to scratch 
that itch. We have less of a technical problem, not to downplay our tech debt, 
as we’re still pushing patches and shuffling reviews. However, we have a huge 
perception problem and equally large marketing problem, which is apparently an 
unwritten side job of being a PTL. We didn’t get that memo until the Big Tent 
was deemed too smothering. The fun part about being a PTL with effectively no 
team is that, when you or your counterpart isn’t actively marketing and 
spending more time making noise than working, people call you dead to your 
face. Even when you spend the time and money to go to marketing events.

--
Best,

Samuel Cassiba



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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[feilong]

On 15/07/17 03:45, Ed Leafe wrote:

On Jul 13, 2017, at 10:32 PM, Fei Long Wang  wrote:


I agree with Zane for most of the parts. But one thing I don't really
understand is, why OpenStack community is still confusing at the IaaS,
PaaS and SaaS, does the classification really mater at nowadays? Do we
really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
Google Cloud say that? I think they're just providing the service their
customer want.

Sure, they may not distinguish those things publicly, but in their internal 
development teams it is very likely that they understand these boundaries. And 
just for another quick example, from the Azure site:

https://azure.microsoft.com/en-us/overview/azure-vs-aws/

"We are the only cloud provider recognized in the industry as having leading 
solutions in IaaS, PaaS, and SaaS. And Azure PaaS platform services can help you be 
more productive and increase your ROI according to this Forrester Total Economic 
Impact study.”

So I don’t think that this distinction is peculiar to OpenStack.


Yep, there is no conflict between you and me. It's good to understand 
the XaaS boundary within OpenStack community, such as there is no 
argument to say Zaqar is a PaaS layer service. What I'm saying is, is it 
really necessary to limit OpenStack only on IaaS?


I can see the contradiction happening in OpenStack community. OpenStack 
are successful  on the IaaS layer as a de facto open standard. So we'd 
like to grow to get a big success. But we're running into some troubles 
because we're running too fast. Then some people said, we should stop 
grow the scope of OpenStack, let's just focus on IaaS. However, that 
shouldn't be the excuse to stop building a better ecosystem around 
OpenStack. If the classification is really matter, then we can define 
(we already have?) the core service at IaaS layer. But I still want to 
see some upper layer services within OpenStack community, such as LBaaS, 
DNSaaS, MQaaS, etc, etc.


Just my $0.02



-- Ed Leafe






__
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


--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Ed Leafe]

On Jul 14, 2017, at 2:17 PM, Zane Bitter  wrote:

> * The pool of OpenStack developers is a fixed resource, and if we make it 
> clear that some projects are unwelcome then their developers will be 
> reassigned to 'core' projects in a completely zero-sum process. (Nnope.)

Yeah, I’ve heard this many times, and always shake my head. If I want to work 
on X, and X is not in OpenStack governance, I’m going to work on that anyway 
because I need it. Or maybe on a similar project. I’m going to scratch my itch.

> * While code like e.g. the Nova scheduler might be so complicated today that 
> even the experts routinely complain about its terrible design,[1] if only we 
> could add dozens more cooks (see above) it would definitely get much simpler 
> and easier to maintain. (Bwahahahahahahaha.)

No, they need to appoint me as the Scheduler Overlord with the power to smite 
all those who propose complicated code!

> * Once we make it clear to users that under no circumstances will we ever 
> e.g. provide them with notifications about when a server has failed, ways to 
> orchestrate a replacement, and an API to update DNS to point to the new one, 
> then they will finally stop demanding bloat-inducing VMWare/oVirt-style 
> features that enable them to treat cloud servers like pets. (I. don't. even.)


Again, itches will be scratched. What I think is more important is a marketing 
issue, not a technical one. When I think of what it means to be a “core” 
project, I think of things that people looking to “get cloudy” would likely 
want. It isn’t until you start using a cloud that the additional projects you 
mention become important. So simplifying what is presented to the cloud market 
is a good thing, as it won’t confuse people as to what OpenStack is. But that 
doesn’t require any of the other projects be stopped or in any way discouraged.

-- Ed Leafe





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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Zane Bitter]

On 13/07/17 23:32, Fei Long Wang wrote:

I agree with Zane for most of the parts. But one thing I don't really
understand is, why OpenStack community is still confusing at the IaaS,
PaaS and SaaS, does the classification really mater at nowadays? Do we
really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
Google Cloud say that? I think they're just providing the service their
customer want.


I sort-of agree that it shouldn't matter. But we do need to communicate 
clearly, and those terms commonly come up, and if we don't have a shared 
understanding of what they mean then we're going to be talking past each 
other a lot.


So a common thing for folks to say is that OpenStack should concentrate 
on IaaS, not PaaS. And this is fairly widely agreed-upon. Even I mostly 
agree!


AWS has a PaaS. It's called Elastic Beanstalk. I don't hear about it 
much. Without having seen numbers for any of them, I would guess that 
there are far more users using PaaS services that run on top of AWS's 
IaaS (e.g. Heroku, OpenShift Online) than there are using Elastic 
Beanstalk. Google's PaaS (AppEngine) hasn't been a runaway success 
either. That's a good argument for leaving PaaS to other open source 
projects - it's a complex space with lots of innovation happening and 
there's no reason to think that we need to pick only one and control it.


Unfortunately, when a lot of people say OpenStack should do "IaaS only" 
they don't mean "equivalents of basically anything that AWS does except 
Elastic Beanstalk is fair game", they mean "only the equivalents of EC2, 
VPC, and EBS are fair game". This, they believe, will lead to the holy 
grail of a "small, stable core", presumably predicated on the following 
assumptions:


* The pool of OpenStack developers is a fixed resource, and if we make 
it clear that some projects are unwelcome then their developers will be 
reassigned to 'core' projects in a completely zero-sum process. (Nnope.)


* While code like e.g. the Nova scheduler might be so complicated today 
that even the experts routinely complain about its terrible design,[1] 
if only we could add dozens more cooks (see above) it would definitely 
get much simpler and easier to maintain. (Bwahahahahahahaha.)


* Once we make it clear to users that under no circumstances will we 
ever e.g. provide them with notifications about when a server has 
failed, ways to orchestrate a replacement, and an API to update DNS to 
point to the new one, then they will finally stop demanding 
bloat-inducing VMWare/oVirt-style features that enable them to treat 
cloud servers like pets. (I. don't. even.)


That's a... ahem... let's just say it's a difficult case to make, but 
it's much easier to say "OpenStack should just be IaaS" and let everyone 
substitute in their own different definitions of IaaS and nod in 
agreement. So the terminology is unlikely to go away ;)


cheers,
Zane.

[1] https://twitter.com/jaypipes/status/885278601821769728


On 14/07/17 05:03, Zane Bitter wrote:

On 29/06/17 10:55, Monty Taylor wrote:

(Incidentally, I think it's unworkable to have an IaaS without DNS.
Other people have told me that having an IaaS without LBaaS or a
message queuing service is unworkable, while I neither need nor want
either of those things from my IaaS - they seem like PaaS components
to me)


I resemble that remark, so maybe it's worth clarifying how I see things.

In many ways the NIST definitions of SaaS/PaaS/IaaS from 2011, while
helpful to cut through the vagueness of the 'cloud' buzzword and frame
the broad outlines of cloud service models (at least at the time),
have proven inadequate to describe the subtlety of the various
possible offerings. The only thing that is crystal clear is that LBaaS
and message queuing are not PaaS components ;)

I'd like to suggest that the 'Platform' in PaaS means the same thing
that it has since at least the '90s: the Operating System and possibly
there language runtime if any. The difference between PaaS and IaaS in
terms of compute is that in the latter case you're given a machine and
you install whatever platform you like on it, while in the former the
platform is provided as a service. Hence the name.

To the extent that hardware load balancers are used, LBaaS is pretty
clearly IaaS. Hardware is infrastructure, if you provide access to
that as a service it's Infrastructure as a Service. QED. It's also
possible to provide software load balancers as a service. Technically
I guess this is SaaS. Theoretically you could make an argument that an
API that can abstract over either hardware or software load balancers
is not "real" IaaS. And I would label that argument as BS sophistry :)

The fact that PaaS implementations use load balancers internally is
really neither here nor there.

You can certainly build a useful cloud without LBaaS. That just means
that anybody who needs load balancing will have to spin up their 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Ed Leafe]

On Jul 13, 2017, at 10:32 PM, Fei Long Wang  wrote:

> I agree with Zane for most of the parts. But one thing I don't really
> understand is, why OpenStack community is still confusing at the IaaS,
> PaaS and SaaS, does the classification really mater at nowadays? Do we
> really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
> SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
> Google Cloud say that? I think they're just providing the service their
> customer want.

Sure, they may not distinguish those things publicly, but in their internal 
development teams it is very likely that they understand these boundaries. And 
just for another quick example, from the Azure site:

https://azure.microsoft.com/en-us/overview/azure-vs-aws/

"We are the only cloud provider recognized in the industry as having leading 
solutions in IaaS, PaaS, and SaaS. And Azure PaaS platform services can help 
you be more productive and increase your ROI according to this Forrester Total 
Economic Impact study.”

So I don’t think that this distinction is peculiar to OpenStack.

-- Ed Leafe






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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Fei Long Wang]

I agree with Zane for most of the parts. But one thing I don't really
understand is, why OpenStack community is still confusing at the IaaS,
PaaS and SaaS, does the classification really mater at nowadays? Do we
really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
Google Cloud say that? I think they're just providing the service their
customer want.


On 14/07/17 05:03, Zane Bitter wrote:
> On 29/06/17 10:55, Monty Taylor wrote:
>> (Incidentally, I think it's unworkable to have an IaaS without DNS.
>> Other people have told me that having an IaaS without LBaaS or a
>> message queuing service is unworkable, while I neither need nor want
>> either of those things from my IaaS - they seem like PaaS components
>> to me)
>
> I resemble that remark, so maybe it's worth clarifying how I see things.
>
> In many ways the NIST definitions of SaaS/PaaS/IaaS from 2011, while
> helpful to cut through the vagueness of the 'cloud' buzzword and frame
> the broad outlines of cloud service models (at least at the time),
> have proven inadequate to describe the subtlety of the various
> possible offerings. The only thing that is crystal clear is that LBaaS
> and message queuing are not PaaS components ;)
>
> I'd like to suggest that the 'Platform' in PaaS means the same thing
> that it has since at least the '90s: the Operating System and possibly
> there language runtime if any. The difference between PaaS and IaaS in
> terms of compute is that in the latter case you're given a machine and
> you install whatever platform you like on it, while in the former the
> platform is provided as a service. Hence the name.
>
> To the extent that hardware load balancers are used, LBaaS is pretty
> clearly IaaS. Hardware is infrastructure, if you provide access to
> that as a service it's Infrastructure as a Service. QED. It's also
> possible to provide software load balancers as a service. Technically
> I guess this is SaaS. Theoretically you could make an argument that an
> API that can abstract over either hardware or software load balancers
> is not "real" IaaS. And I would label that argument as BS sophistry :)
>
> The fact that PaaS implementations use load balancers internally is
> really neither here nor there.
>
> You can certainly build a useful cloud without LBaaS. That just means
> that anybody who needs load balancing will have to spin up their own
> software load balancer to do it. But that has a couple of
> consequences. One is that every application developer has to build
> their own orchestration to update the load balancer configuration when
> it needs to change. The other is that they're stuck with the least
> common denominator - if you use one cloud that doesn't have an LBaaS
> API, even one backed by software load balancers, then you won't be
> able to take advantage of hardware load balancers on another cloud
> without rewriting a chunk of your application. That's a big concern
> for OpenStack, which has application portability as one of its
> foremost goals. Thus an IaaS cloud that includes LBaaS is considerably
> more valuable than one that does not, for a large range of very common
> use cases.
>
> This is pretty much the same argument as I would make for DNSaaS.
> Without it you're developing your own orchestration and/or manually
> updating stuff every time you make a change in your infrastructure,
> which pretty much negates the benefits of IaaS for a very large subset
> of applications and leaves you stuck back in the pre-aaS days where
> making any changes to where your application ran was slow and painful.
> That's despite the fact that DNSaaS is arguably pure SaaS. This is
> where the NIST model breaks down IMHO. We tend to assume that only
> stuff that faces end users is SaaS and therefore everything
> developer-facing has to fall into either IaaS/PaaS. This results in
> IaaS developers treating "PaaS" as a catch-all bucket for "everything
> application developer-facing that I don't think is infrastructure",
> rather than a term that has meaning in itself.
>
> This confusion leads to the implicit argument that these kinds of
> developer-facing SaaS offerings are only useful to applications
> running in a PaaS, and therefore should be Someone Else's Problem,
> which is WRONG. It's wrong because different parts of an application
> have different needs. Just because I need to tweak the kernel
> parameters on my app server, it doesn't follow that I need to tweak
> the kernel parameters on my load balancer, or my database, too. It
> just doesn't.
>
> At one level, a message queue falls into the same bucket as other SaaS
> components (like DBaaS, sometimes LBaaS, ). Something that's useful
> to a subset of applications running in either an IaaS or a PaaS. The
> subset of applications that would use it is probably quite a bit
> smaller than the subset that would use e.g. LBaaS.
>
> However, there's also another dimension to 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-07-13 13:03:26 -0400 (-0400), Zane Bitter wrote:
[...]
> This is pretty much the same argument as I would make for DNSaaS.
> Without it you're developing your own orchestration and/or
> manually updating stuff every time you make a change in your
> infrastructure, which pretty much negates the benefits of IaaS for
> a very large subset of applications and leaves you stuck back in
> the pre-aaS days where making any changes to where your
> application ran was slow and painful.
[...]

For the most part I would agree with you, and in fact I myself run
geographically-distributed authoritative nameservers for my own
domains on general purpose virtual machines so I can have better
control over things like DNSSEC but there is one exception.

At least I (and many sysadmins I know personally or professionally)
expect working reverse DNS for the systems they maintain. Reverse
DNS either has to be set through or delegated by the holder of the
IP address assignments (the LIR in IANA's terminology). If you can't
get _some_ direct mechanism from your provider to set reverse DNS
entries for the systems you're running there, then that's bad. If
they don't provide an API or some tight integration with their
server management automation to set your chosen reverse DNS entries
on each new system you boot, and you're instead relegated to
submitting a trouble ticket or change request to get that added
afterward, then it's not an especially functional service.

It doesn't matter that I can boot a server in your environment in
seconds if it then sits there for hours or days before I have proper
reverse DNS added so I feel comfortable putting it into production.
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][tc] How to deal with confusion around "hosted projects"

[Zane Bitter]

On 29/06/17 10:55, Monty Taylor wrote:
(Incidentally, I think it's unworkable to have an IaaS without DNS. 
Other people have told me that having an IaaS without LBaaS or a message 
queuing service is unworkable, while I neither need nor want either of 
those things from my IaaS - they seem like PaaS components to me)


I resemble that remark, so maybe it's worth clarifying how I see things.

In many ways the NIST definitions of SaaS/PaaS/IaaS from 2011, while 
helpful to cut through the vagueness of the 'cloud' buzzword and frame 
the broad outlines of cloud service models (at least at the time), have 
proven inadequate to describe the subtlety of the various possible 
offerings. The only thing that is crystal clear is that LBaaS and 
message queuing are not PaaS components ;)


I'd like to suggest that the 'Platform' in PaaS means the same thing 
that it has since at least the '90s: the Operating System and possibly 
there language runtime if any. The difference between PaaS and IaaS in 
terms of compute is that in the latter case you're given a machine and 
you install whatever platform you like on it, while in the former the 
platform is provided as a service. Hence the name.


To the extent that hardware load balancers are used, LBaaS is pretty 
clearly IaaS. Hardware is infrastructure, if you provide access to that 
as a service it's Infrastructure as a Service. QED. It's also possible 
to provide software load balancers as a service. Technically I guess 
this is SaaS. Theoretically you could make an argument that an API that 
can abstract over either hardware or software load balancers is not 
"real" IaaS. And I would label that argument as BS sophistry :)


The fact that PaaS implementations use load balancers internally is 
really neither here nor there.


You can certainly build a useful cloud without LBaaS. That just means 
that anybody who needs load balancing will have to spin up their own 
software load balancer to do it. But that has a couple of consequences. 
One is that every application developer has to build their own 
orchestration to update the load balancer configuration when it needs to 
change. The other is that they're stuck with the least common 
denominator - if you use one cloud that doesn't have an LBaaS API, even 
one backed by software load balancers, then you won't be able to take 
advantage of hardware load balancers on another cloud without rewriting 
a chunk of your application. That's a big concern for OpenStack, which 
has application portability as one of its foremost goals. Thus an IaaS 
cloud that includes LBaaS is considerably more valuable than one that 
does not, for a large range of very common use cases.


This is pretty much the same argument as I would make for DNSaaS. 
Without it you're developing your own orchestration and/or manually 
updating stuff every time you make a change in your infrastructure, 
which pretty much negates the benefits of IaaS for a very large subset 
of applications and leaves you stuck back in the pre-aaS days where 
making any changes to where your application ran was slow and painful. 
That's despite the fact that DNSaaS is arguably pure SaaS. This is where 
the NIST model breaks down IMHO. We tend to assume that only stuff that 
faces end users is SaaS and therefore everything developer-facing has to 
fall into either IaaS/PaaS. This results in IaaS developers treating 
"PaaS" as a catch-all bucket for "everything application 
developer-facing that I don't think is infrastructure", rather than a 
term that has meaning in itself.


This confusion leads to the implicit argument that these kinds of 
developer-facing SaaS offerings are only useful to applications running 
in a PaaS, and therefore should be Someone Else's Problem, which is 
WRONG. It's wrong because different parts of an application have 
different needs. Just because I need to tweak the kernel parameters on 
my app server, it doesn't follow that I need to tweak the kernel 
parameters on my load balancer, or my database, too. It just doesn't.


At one level, a message queue falls into the same bucket as other SaaS 
components (like DBaaS, sometimes LBaaS, ). Something that's useful 
to a subset of applications running in either an IaaS or a PaaS. The 
subset of applications that would use it is probably quite a bit smaller 
than the subset that would use e.g. LBaaS.


However, there's also another dimension to asynchronous messaging in 
particular. If a cloud needs to notify an application about events in or 
changes to its infrastructure, then if it has a built-in *reliable* 
message queue API it can reuse it to deliver these notifications. 
(Actually, I would put it the other way around: if a cloud has an API to 
deliver messages to applications from the infrastructure, it can also 
allow applications to reuse this capability for their own purposes.) 
Again, you can certainly have an IaaS cloud that doesn't provide an 
asynchronous messaging capability. But it will 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Flavio Percoco]

On 28/06/17 16:50 +0200, Thierry Carrez wrote:

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

1- it lets us set up code repositories and testing infrastructure before
a project applies to be an official OpenStack project.

2- it lets us host things that are not openstack but which we work on
(like abandoned Python libraries or GPL-licensed things) in a familiar
environment

3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I would argue that we could handle (1) and (2) within our current
governance.

For (1) we could have an "onboarding" project team that would help
incoming projects through the initial steps of becoming an openstack
project. The team would act as an umbrella team, an experimental area
for projects that have some potential to become an OpenStack project one
day. There would be a time limit -- if after one year(?) it looks like
you won't become an openstack project after all, the onboarding team
would clean you up. I actually think a bit more project mentoring would
serve us better than our current hands-free approach.


I'd say that we should do this regardless. I believe in mentoring and I see
great value in onboarding projects. It's a job in itself and I think having a
team of volunteers doing that would be awesome.

One could argue that, given the current status of some of the teams, it'd not be
wise to create a new one that, well, requires more volunteers. However, I think
that it doesn't have to take volunteer's full time and it'd be great for new
projects.

I've mentored new teams and I know a few other folks have done it, including
Thierry. I wonder how many of the currently hosted teams feel they need
menotring.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Flavio Percoco]

On 28/06/17 16:50 -0500, Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I
do not believe that doing this provides any value to us as a
community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?

* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still
going to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.


I agree with Monty on this one. My main concern with the proposal is that we'll
end up exactly where we are at now because we simply can't make everyone happy.
There are folks confused by what Google says (mainly people not familiar with
OpenStack) and there are folks confused because they disagree with what
OpenStack *is*.

As others proposed in this thread (or was it another thread?), I'd suggest we
first finish working on the vision, and take a few more steps on this area
before we do any other major change in the community. That way we can measure
whether the changes we're discussing serve such vision.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Flavio Percoco]

On 29/06/17 10:33 -0500, Monty Taylor wrote:

On 06/29/2017 10:00 AM, Jimmy McArthur wrote:




Thierry Carrez 
June 29, 2017 at 9:54 AM

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.

It might be a giganormous amount of maintenance work, but it's the
only way you're going to properly fix the Google problem. You can
still keep the data archived, but I would change the link to
something like /inactive-projects/meteos, again with the proper
redirects. And again, updating the sitemap.

As far as github, if the project is legitimately dead, the repo
should be set to private.

Just because something is a lot of work doesn't mean it's not worth doing :)


When we retire a project, we land a commit to that project that
removes all of the content and replaces it with a commit message that
indicates that the project has been retired.

We could probably add a flag to our projects.yaml file that is
"retired" or something, that would cause the cgit mirror config to
stop listing the project (the git repo would still exist and still be
cloneable, it just wouldn't show up in the web listings)

Since github for us is just a read-only mirror, I would not object to
having that flag cause our automation to delete the mirror repo from
github. Again, we would not be deleting any content, we would just be
un-publishing it.

I do not believe either of those would be much work- other than
someone needing to go through and flag retired projects as such in
projects.yaml - and I do not believe there are any downsides.

There is still the wiki- which is still a wiki.


Sometimes I wonder if we still need to maintain a Wiki. I guess some projects
still use it but I wonder if the use they make of the Wiki could be moved
somewhere else.

For example, in the TC we use it for the Agenda but I think that could be moved
to an etherpad. Things that should last forever should be documented somewhere
(project repos, governance repo in the TC case) where we can actually monitor
what goes in and easily clean up.

That said, I agree, wiki is still a wiki.
Flavio


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Bogdan Dobrelya]

On 28.06.2017 23:50, Monty Taylor wrote:
> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The thread went
>> in a lot of directions, including discussing GitHub mirroring strategy,
>> what makes projects want to be official, the need for returning to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we should stop
>> using it. The issue is, merely stopping using it won't be enough. We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even with the
>> expansive "are you one of us" definition. Arguably the most confusing
>> aspect is the "openstack/" prefix in the git repository name, which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue on the
>> edges, or you can treat the root cause. Neither of those options is
>> really an OpenStack  governance change (or "big tent" change) -- they
>> are more about what to do with things that are actually *not* in our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer when
>> things are not official. The thread above discussed a lot of potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
>> way to tag all projects on GitHub that are not official, or mirror them
>> to another organization, or stop mirroring them altogether. We could
>> remove the openstack/ prefix from all the projects we host. We could
>> actively mark all wiki pages that are not about an official project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
> 
> I disagree that this is removing the root cause.
> 
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
> 
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It
> is suggested that the existence of git repos in the openstack/ github
> org is confusing to people. And our reaction to that is to cut off
> access to our Open Source tools that we set up to collaboratively
> develop cloud software and tell people to go use the thing that people
> suggest is one of the causes of people being confused?
> 
> * People are not 'confused' by what OpenStack is.
> 
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going
> to be unhappy with cloudkitty, congress and karbor.
> 
> Such people are under the misguided impression that kicking cloudkitty
> out of OpenStack will somehow cause Nova features to land quicker. I
> can't even begin to express all of the ways in which it's wrong. We
> aren't a top-down corporate structure and we can't 'reassign' humans -
> but even if we WERE - this flawed thinking runs afoul of the Mythical
> Man Month.
> 
> * Kicking non-official things out will not help
> 
> If I'm wrong about the above and it really is all just about not being
> able to navigate a set of 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-30 11:31:01 +1000 (+1000), Joshua Hesketh wrote:
[...]
> has anybody looked at how difficult it would be to actually to
> fix gerrit,

There was an abandoned attempt to implement it in core:

https://gerrit-review.googlesource.com/q/project:gerrit+topic:rename-project

And there's still the vestige of an empty plugin attempt which never
had any code pushed up to it:

https://gerrit.googlesource.com/plugins/rename-project/

Being in Java is a bit of a roadblock for me personally to reattempt
to tackle it. I'm just a lowly sysadmin so if it's not
c/shell/perl/python my learning curve is pretty steep.

Given that Gerrit is used lots of places by lots of orgs and yet
their forums have a scant handful of posts on this subject from
people who suddenly discovered they needed to rename a single
project after years of running, I have to ask whether what we're
doing needing to rename things constantly isn't just plain counter
to the way the software is intended to be applied. Makes me think we
should just be finding ways to avoid renaming things over and over,
even if that means switching all repository names to UUIDs (okay,
mostly kidding there... _mostly_).

> automate github (perhaps through a newer API or simulating
> those clicks etc),

I poked around in the GH v3 REST API an v4 GraphQL-based API docs
and couldn't spot any methods for transferring a repo between orgs.
Given that the operation in the WebUI requires an account with
membership in both involved orgs, they may deem it beneath the value
threshold for inclusion. Also, I'd personally much rather stop
having Gerrit push replicate into GH, and hand maintenance of a
mirror there off to some other volunteers within the community who
have more of an interest in similar social media platforms.

> come up with a creative fix to git remotes (redirects, updating
> via git review or something) etc.
[...]

I've already been mulling over some ideas for useful
redirects/rewrites on our git.openstack.org service and that's not
too hard for HTTP(S) remotes to deal with, but for Git protocol
requests I don't think it's possible without significant
modification to the backend service (best I can come up with is
symlinking on the underlying filesystem, and maybe that's "good
enough").

But to circle back around to my earlier point, assuming that we're
just going to need to accept a constant flood of renames and then
try to engineer solutions to make that marginally less painful is
stretching my suspension of disbelief here. I'd rather find a way to
avoid project renames just for the sake of governance
inclusion/exclusion. We don't have any solid evidence that it will
"fix" the external confusion around OpenStack at all, but we
definitely know it will create a lot of additional work. I have a
hard time seeing justification in such a tradeoff.
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Fox, Kevin M wrote:
> [...]
> So whats really unclear to end users is that when they talk about a piece of 
> "openstack" they may be talking about a great many things:
> 1. is it managed under the 4 opens
> 2. is it in github.com/openstack.
> 3. is it under openstack governance.
> 4. is it an 'openstack project' (what does this mean anymore. I thought that 
> was #3, but maybe not?)
> 5. is "openstack" part of its title
> 
> Is a project part of openstack if it meets one of those? all of them? or some 
> subset? If we can't answer it, I'm not sure users will ever understand it.

We can totally answer it. The "official" answer is (3) (synonymous to
(4)). The trick is, the project list on our governance website is a
*lot* less visible than (2) or (5), so it's very easy to appear as an
openstack project while not being one. Which is precisely the confusion
I'd like us to clear out one way or another.

My initial suggestion (on the other thread) was to give some brand name
to things that are hosted/companion/friends/neighbors/stackforge, so
that we can more easily apply that mark and incrementally reduce the
confusion.

The thread went on discussing other corrective measures at the edge
(like turning github.org/openstack into more curated content, and/or
removing the openstack/ prefix from all of our repositories). All good
suggestions.

This thread introduced yet another possibility: no longer accept hosting
for projects outside of openstack governance. This clarifies things a
lot, but presents challenges of its own, as that space was pretty
convenient to bootstrap projects or host companion projects, as well as
build a community.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Steven Dake]

Agree.

Regards
-steve

On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor  wrote:

> On 06/28/2017 11:27 PM, Steven Dake wrote:
>
>
>>
>> On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor > > wrote:
>>
>> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC
>> workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The
>> thread went
>> in a lot of directions, including discussing GitHub mirroring
>> strategy,
>> what makes projects want to be official, the need for returning
>> to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>> > e/118368.html>
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we
>> should stop
>> using it. The issue is, merely stopping using it won't be enough.
>> We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to
>> see what
>> is a part of OpenStack and what's not. If you google "openstack
>> machine
>> learning", the first hits are Cognitive and Meteos, and it's
>> impossible
>> to tell that those are actually not OpenStack projects. One of
>> those has
>> been dead for 2 years -- having people think that those are
>> official
>> projects hurts all the OpenStack projects, by lowering
>> expectations
>> around what that means, in terms of quality, maintenance, or
>> community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's
>> nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even
>> with the
>> expansive "are you one of us" definition. Arguably the most
>> confusing
>> aspect is the "openstack/" prefix in the git repository name,
>> which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue
>> on the
>> edges, or you can treat the root cause. Neither of those options
>> is
>> really an OpenStack  governance change (or "big tent" change) --
>> they
>> are more about what to do with things that are actually *not* in
>> our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer
>> when
>> things are not official. The thread above discussed a lot of
>> potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could
>> find a
>> way to tag all projects on GitHub that are not official, or
>> mirror them
>> to another organization, or stop mirroring them altogether. We
>> could
>> remove the openstack/ prefix from all the projects we host. We
>> could
>> actively mark all wiki pages that are not about an official
>> project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is
>> that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop
>> offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The
>> benefits of
>> offering that service are:
>>
>>
>> I disagree that this is removing the root cause.
>>
>> I believe this is reacting to a misunderstanding by hiding from it.
>> I do not believe that doing this provides any value to us as a
>> community.
>>
>> Even though we do not actually use github for development, we have
>> implicitly accepted the false premise that github is a requirement.
>> It is suggested that the existence of git repos in the openstack/
>> github org is confusing to people. And our reaction to that is to
>> cut off access to our Open 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

On Fri, Jun 30, 2017 at 12:18 AM, Jeremy Stanley  wrote:

> On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> > So I apologise if this has already been suggested/discussed (the
> > long threads are difficult to keep up with), but has it been
> > considered to go back to using a stackforge namespace?
> [...]
>
> Back in the bad ol' days when we had a separate namespace for
> unofficial projects, it seemed to me like newcomers were just as
> confused as they are now, perhaps even more so. People like to
> forget, or wax nostalgic, or simply weren't around to see it first
> hand back then; so I agree it's probably worth rehashing the pain
> points as it's been a long time since I can recall anyone
> enumerating them.
>
> Gerrit's design assumes project names (including any prefixed
> namespace) never change. This means project renames in Gerrit are
> painful and disruptive (service outage for everyone, Git remote
> changes for anyone working on that repo, risk of breaking things
> with a SQL update query or directory move, et cetera). There is no
> good automation for transfers between orgs in GH either so handling
> this is a manual process involving lot of clicking around in a Web
> browser. Project renames also touch other systems (our many Git
> servers, StoryBoard) so more places to make mistakes or miss
> something.
>
> As a result, we would want to actively discourage repos moving from
> the stackforge namespace into the openstack namespace (or vice
> versa) which creates an artificial hurdle for projects seeking to
> become official. This causes them to place an urgent pressure on the
> Infra team which makes it harder for us to ease the pain of renames
> by batching them up and processing them less frequently. We
> similarly would no longer be allowed to create repos directly in the
> openstack namespace without prior approval from the TC, which puts
> the brakes on the current flow where teams can create a new repo as
> quickly as the project-config-cores review the change and then work
> on the corresponding governance addition in parallel with doing
> their project development.
>
> In the past the ability to push most of the work of doing renames
> onto the Infra team created a perverse incentive for projects to
> start unofficial so they didn't have to wait on the TC, and then ask
> for a rename once they got approval rather than waiting to start
> work until the TC approved their request. It's hard for the Infra
> team to effectively deter that sort of behavior because the most we
> can do is ask authors of their intentions and then trust that
> they're being up front about a lack of interest in becoming official
> (and that they're unlikely to change their minds about it later).
>
> Unfortunately, hosting unofficial projects grants official teams a
> license to experiment in that space rather than taking
> responsibility up front, and this is detrimental to our community as
> a whole. It also gives new teams an easy excuse to put off applying
> to become official until later since they get most of the
> infrastructure benefits right away regardless. If we could get rid
> of this pervasive temptation to "incubate" ideas out from under the
> shadow of governance then maybe that would make maintaining the rest
> under a different namespace slightly less of a burden, as the need
> to move repos between namespaces would then be far less common or
> urgent.
> --
> 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
>
>
Hey Jeremy,

Thanks for that, it's a good refresher. I'm aware of the technical
challenges however (and I think I did a poor job of saying this) I was
suggesting that if we suspend the technical issues for the purpose of this
discussion what does it look like. In other words, lets assume we can
easily move between namespaces (and even git remotes aren't a problem), in
this case is returning to something like stackforge advantageous?

Then, if so, has anybody looked at how difficult it would be to actually to
fix gerrit, automate github (perhaps through a newer API or simulating
those clicks etc), come up with a creative fix to git remotes (redirects,
updating via git review or something) etc.

This possibly isn't helpful as I'm unfortunately not in a position to be
able to volunteer to work on any of the above. Realistically I imagine that
the amount of work is not feasible and that is one of the reasons we moved
away from multiple name spaces. I'm just wondering if that is still the
case.

Cheers,
Josh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 19:25:09 + (+), Tim Bell wrote:
[...]
> Can an ‘official’ project be deprecated? The economics say yes.
> The consumer confidence impact would be substantial.
[...]

Does https://review.openstack.org/475721 count? What about
https://review.openstack.org/452086 or, going back a ways,
https://review.openstack.org/376609 maybe? We deprecate official
projects by removing them from our governance with some regularity,
though being realistic it's no more than a few a year.
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][tc] How to deal with confusion around "hosted projects"

[Zane Bitter]

On 29/06/17 10:18, Jeremy Stanley wrote:

Gerrit's design assumes project names (including any prefixed
namespace) never change. This means project renames in Gerrit are
painful and disruptive (service outage for everyone, Git remote
changes for anyone working on that repo, risk of breaking things
with a SQL update query or directory move, et cetera). There is no
good automation for transfers between orgs in GH either so handling
this is a manual process involving lot of clicking around in a Web
browser. Project renames also touch other systems (our many Git
servers, StoryBoard) so more places to make mistakes or miss
something.


Or just abandon all pending patches, delete the branches, and clone the 
git repo to a fresh project?


For a project at an early enough stage that they're just managing to 
convince the TC that they have the critical mass to be a 'going concern' 
following the 4 opens (and thus able to become an official project), 
that's not even that onerous. We effectively did it with Heat when 
moving from GitHub to StackForge and at worst it was a minor annoyance 
for a couple of days.


We can't keep giving away our trademark to literally anybody who comes 
along. In retrospect, if our top priority was to avoid renaming we 
should have moved the official projects to the stackforge/ namespace 
instead of the other way around.


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Fox, Kevin M]

Part of the confusion is around what is allowed to use the term openstack and 
the various ways its used.

we have software such as github.com/openstack/openstack-helm,

which is in the openstack namespace, has openstack in its title, but not under 
tc governance. 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

But it also also has stated its an 'openstack project'.

(not trying to pick on openstack-helm here. just the most recent example I can 
think of that shows off the various ways something can/can't be "openstack" 
today)

So whats really unclear to end users is that when they talk about a piece of 
"openstack" they may be talking about a great many things:
1. is it managed under the 4 opens
2. is it in github.com/openstack.
3. is it under openstack governance.
4. is it an 'openstack project' (what does this mean anymore. I thought that 
was #3, but maybe not?)
5. is "openstack" part of its title

Is a project part of openstack if it meets one of those? all of them? or some 
subset? If we can't answer it, I'm not sure users will ever understand it.

This is separate entirely from the maturity of the software and the level of 
integration with other openstack software issue too. :/

Thanks,
Kevin


From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, June 29, 2017 12:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] How to deal with confusion around 
"hosted projects"

> On 29 Jun 2017, at 17:35, Chris Friesen <chris.frie...@windriver.com> wrote:
>
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
>
>> We are already WELL past where we can solve the problem you are describing.
>> Pandora's box has been opened - we have defined ourselves as an Open 
>> community.
>> Our only requirement to be official is that you behave as one of us. There is
>> nothing stopping those machine learning projects from becoming official. If 
>> they
>> did become official but were still bad software - what would we have solved?
>>
>> We have a long-time official project that currently has staffing problems. If
>> someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
>> that
>> the contribution rate has fallen off recently they could get the impression 
>> that
>> OpenStack is a bunch of dead crap.
>>
>> Inclusion as an Official Project in OpenStack is not an indication that 
>> anyone
>> thinks the project is good quality. That's a decision we actively made. This 
>> is
>> the result.
>
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level of stability/usefulness/maturity/quality" to help newcomers weed out 
> projects that are under TC governance but are not ready for prime time.
>

There is certainly a concern on the operator community as to how viable/useful 
a project is (and how to determine this). Adopting too early makes for a very 
difficult discussion with cloud users who rely on the function.

Can an ‘official’ project be deprecated? The economics say yes. The consumer 
confidence impact would be substantial.

However, home grown solutions where there is common interest implies technical 
debt in the long term.

Tim

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

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

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Tim Bell]

> On 29 Jun 2017, at 17:35, Chris Friesen  wrote:
> 
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
> 
>> We are already WELL past where we can solve the problem you are describing.
>> Pandora's box has been opened - we have defined ourselves as an Open 
>> community.
>> Our only requirement to be official is that you behave as one of us. There is
>> nothing stopping those machine learning projects from becoming official. If 
>> they
>> did become official but were still bad software - what would we have solved?
>> 
>> We have a long-time official project that currently has staffing problems. If
>> someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
>> that
>> the contribution rate has fallen off recently they could get the impression 
>> that
>> OpenStack is a bunch of dead crap.
>> 
>> Inclusion as an Official Project in OpenStack is not an indication that 
>> anyone
>> thinks the project is good quality. That's a decision we actively made. This 
>> is
>> the result.
> 
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level of stability/usefulness/maturity/quality" to help newcomers weed out 
> projects that are under TC governance but are not ready for prime time.
> 

There is certainly a concern on the operator community as to how viable/useful 
a project is (and how to determine this). Adopting too early makes for a very 
difficult discussion with cloud users who rely on the function. 

Can an ‘official’ project be deprecated? The economics say yes. The consumer 
confidence impact would be substantial.

However, home grown solutions where there is common interest implies technical 
debt in the long term.

Tim

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

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 08:49:19 -0500 (-0500), Jimmy McArthur wrote:
[...]
> If there is specifically confusion around Google searches, I'd
> suggest as a first step to spend some time working on redirects
> for dead projects and very clearly updating documentation. For all
> of Google's magic, there are some simple and easy rules to help
> correct bad search data.

A good idea, but we're actually not (yet) letting Google or other
robots-abiding crawlers index our repositories on git.openstack.org
until https://review.openstack.org/427959 or something like it
lands.

> Additionally, we just implemented SwifType on OpenStack.org and
> docs.o.o b/c Google deprecated their Site Search product. We have
> a ton of control over that search and can very easily modify
> search results.

At the moment we maintain a specialized search engine for source
code at http://codesearch.openstack.org/ which is a bit more
empowering than basic Web content searches, and it might be a good
idea to see if we can better integrate that in the places where
people see a need for it.

> Let me know if I can be of service on any of these fronts.

Always appreciated!
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][tc] How to deal with confusion around "hosted projects"

[Andreas Jaeger]

On 2017-06-29 17:33, Monty Taylor wrote:
> On 06/29/2017 10:00 AM, Jimmy McArthur wrote:
>>
>>
>>> Thierry Carrez 
>>> June 29, 2017 at 9:54 AM
>>>
>>> Unfortunately, those pages just exist -- those hundreds of projects
>>> projects might be inactive, they still have git repositories and wiki
>>> pages. We could more actively clean them up (and then yes, adjusting the
>>> corresponding Google juice), but (1) we don't really have any right to
>>> do so unless we get permission (which is hard to get from dead
>>> projects), and (2) that's a giganormous amount of maintenance work.
>> It might be a giganormous amount of maintenance work, but it's the
>> only way you're going to properly fix the Google problem. You can
>> still keep the data archived, but I would change the link to something
>> like /inactive-projects/meteos, again with the proper redirects. And
>> again, updating the sitemap.
>>
>> As far as github, if the project is legitimately dead, the repo should
>> be set to private.
>>
>> Just because something is a lot of work doesn't mean it's not worth
>> doing :)
> 
> When we retire a project, we land a commit to that project that removes
> all of the content and replaces it with a commit message that indicates
> that the project has been retired.
>
Check:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n355

acl-config: /home/gerrit2/acls/openstack/retired.config

So, that's a current mark.

> We could probably add a flag to our projects.yaml file that is "retired"
> or something, that would cause the cgit mirror config to stop listing
> the project (the git repo would still exist and still be cloneable, it
> just wouldn't show up in the web listings)


> Since github for us is just a read-only mirror, I would not object to
> having that flag cause our automation to delete the mirror repo from
> github. Again, we would not be deleting any content, we would just be
> un-publishing it.


> I do not believe either of those would be much work- other than someone
> needing to go through and flag retired projects as such in projects.yaml
> - and I do not believe there are any downsides.

That flagging can be done quickly, see above.

> There is still the wiki- which is still a wiki.

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Doug Hellmann]

Excerpts from Chris Friesen's message of 2017-06-29 09:35:01 -0600:
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
> 
> > We are already WELL past where we can solve the problem you are describing.
> > Pandora's box has been opened - we have defined ourselves as an Open 
> > community.
> > Our only requirement to be official is that you behave as one of us. There 
> > is
> > nothing stopping those machine learning projects from becoming official. If 
> > they
> > did become official but were still bad software - what would we have solved?
> >
> > We have a long-time official project that currently has staffing problems. 
> > If
> > someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
> > that
> > the contribution rate has fallen off recently they could get the impression 
> > that
> > OpenStack is a bunch of dead crap.
> >
> > Inclusion as an Official Project in OpenStack is not an indication that 
> > anyone
> > thinks the project is good quality. That's a decision we actively made. 
> > This is
> > the result.
> 
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level 
> of stability/usefulness/maturity/quality" to help newcomers weed out projects 
> that are under TC governance but are not ready for prime time.
> 
> Chris
> 

It would be. When we made the shift away from the old incubation
process to our current 4-opens-based governance process, we said
the TC was not necessarily the right body to be making that call.
We may have the expertise for one project, but not another. We also
said that because different people could reasonably have different
opinions based on different criteria, The Market or The Community
should produce that information and share it.

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] [all][tc] How to deal with confusion around "hosted projects"

[Chris Friesen]

On 06/29/2017 09:23 AM, Monty Taylor wrote:


We are already WELL past where we can solve the problem you are describing.
Pandora's box has been opened - we have defined ourselves as an Open community.
Our only requirement to be official is that you behave as one of us. There is
nothing stopping those machine learning projects from becoming official. If they
did become official but were still bad software - what would we have solved?

We have a long-time official project that currently has staffing problems. If
someone Googles for OpenStack DBaaS and finds Trove and then looks to see that
the contribution rate has fallen off recently they could get the impression that
OpenStack is a bunch of dead crap.

Inclusion as an Official Project in OpenStack is not an indication that anyone
thinks the project is good quality. That's a decision we actively made. This is
the result.


I wonder if it would be useful to have a separate orthogonal status as to "level 
of stability/usefulness/maturity/quality" to help newcomers weed out projects 
that are under TC governance but are not ready for prime time.


Chris

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 10:00 AM, Jimmy McArthur wrote:




Thierry Carrez 
June 29, 2017 at 9:54 AM

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.
It might be a giganormous amount of maintenance work, but it's the only 
way you're going to properly fix the Google problem. You can still keep 
the data archived, but I would change the link to something like 
/inactive-projects/meteos, again with the proper redirects. And again, 
updating the sitemap.


As far as github, if the project is legitimately dead, the repo should 
be set to private.


Just because something is a lot of work doesn't mean it's not worth doing :)


When we retire a project, we land a commit to that project that removes 
all of the content and replaces it with a commit message that indicates 
that the project has been retired.


We could probably add a flag to our projects.yaml file that is "retired" 
or something, that would cause the cgit mirror config to stop listing 
the project (the git repo would still exist and still be cloneable, it 
just wouldn't show up in the web listings)


Since github for us is just a read-only mirror, I would not object to 
having that flag cause our automation to delete the mirror repo from 
github. Again, we would not be deleting any content, we would just be 
un-publishing it.


I do not believe either of those would be much work- other than someone 
needing to go through and flag retired projects as such in projects.yaml 
- and I do not believe there are any downsides.


There is still the wiki- which is still a wiki.



Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 03:00 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


Sure - but:

* wikis are wikis - people can literally put anything there they want to.
* The number of official projects is much larger than the number of 
unofficial. Removing unofficial projects will not solve any confusion.



* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.


Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.


I understand the confusion you're talking about. Removing unofficial 
projects will not solve it.



* Kicking non-official things out will not help

If I'm wrong about the above and it really is all just about not being
able to navigate a set of repositories that are prefixed with the string
'openstack/', it STILL WON'T HELP.

There are 1049 official repos. There are only 1676 repos in gerrit.

Do we honestly think that people who are confused are going to be less
confused by the number of repos in the sacred 'openstack/' namespace
going from 1676 to 1049? Do we next tell projects they can only have
their primary service managed? Kick out chef, puppet, juju and ansible,
as well as the deb- repos? Because maybe the existence of
openstack/deb-python-oslo.privsep is confusing someone?


Again, I agree, but I think you're missing my point. Kicking
non-official things is not about cutting the number of repositories, or
somehow making the git.openstack.org/cgit front page more navigable. We
are indeed past that.

Kicking non-official things is about stopping blurring the line between
what's "in" openstack and what's "out". It's about someone googling for
machine learning on openstack, finding Cognitive on git.openstack.org
and wiki.openstack.org, assuming it's an official openstack project
based on those domain names, trying to check it out, realizing it's only
4 commits and dead for two years, and assuming OpenStack has pretty low
standards and is a bunch of dead crap. How do you propose we address
*that* ?


I'm not missing your point - I'm disagreeing with your premise and your 
conclusions.


We are already WELL past where we can solve 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Monty Taylor wrote:
> I also continue to challenge the assertion. There are dead projects in
> there for sure- but there are a LOT of non-dead live projects. It's not
> like we have 6 live and 6 dead projects. The overwhelming majority of
> the projects are not dead.

Early results on my analysis says otherwise... Although it's far from
complete I would say about half of them haven't been touched over the
past year. Feel free to help classifying them at:

https://etherpad.openstack.org/p/negative-space-analysis

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Thierry Carrez 
June 29, 2017 at 9:54 AM

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.
It might be a giganormous amount of maintenance work, but it's the only 
way you're going to properly fix the Google problem. You can still keep 
the data archived, but I would change the link to something like 
/inactive-projects/meteos, again with the proper redirects. And again, 
updating the sitemap.


As far as github, if the project is legitimately dead, the repo should 
be set to private.


Just because something is a lot of work doesn't mean it's not worth doing :)


Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.


Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 11:27 PM, Steven Dake wrote:



On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor > wrote:


On 06/28/2017 09:50 AM, Thierry Carrez wrote:

Hi everyone,

Two weeks ago, as a result of a discussion at the Board+TC+UC
workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The
thread went
in a lot of directions, including discussing GitHub mirroring
strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html



Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we
should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.

The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to
see what
is a part of OpenStack and what's not. If you google "openstack
machine
learning", the first hits are Cognitive and Meteos, and it's
impossible
to tell that those are actually not OpenStack projects. One of
those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or
community.

The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's
nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even
with the
expansive "are you one of us" definition. Arguably the most
confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.

I'd say we have two options. We can address the perception issue
on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack  governance change (or "big tent" change) --
they
are more about what to do with things that are actually *not* in our
governance.

Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of
potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could
find a
way to tag all projects on GitHub that are not official, or
mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official
project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is
that it's
a *lot* of work, and it never completely eliminates the confusion.

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The
benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it.
I do not believe that doing this provides any value to us as a
community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement.
It is suggested that the existence of git repos in the openstack/
github org is confusing to people. And our reaction to that is to
cut off access to our Open Source tools that we set up to
collaboratively develop cloud software and tell people to go use the
thing that people suggest is one of the causes of people being confused?

* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people
who express that they think we should only 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Jimmy McArthur wrote:
> Thierry Carrez wrote:
>> The confusion I'm talking about is not the passive-aggressive from
>> people involved in openstack. It's from our prospective new users, who
>> have no idea about our governance, making random searches on Google.
>> It's from people getting hit by marketing message from projects claiming
>> to be official OpenStack projects, while they are not. It's extremely
>> difficult for those to see clearly, especially with all our online
>> presence reinforcing the confusion.
>
> If there is specifically confusion around Google searches, I'd suggest
> as a first step to spend some time working on redirects for dead
> projects and very clearly updating documentation. For all of Google's
> magic, there are some simple and easy rules to help correct bad search
> data.

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Anne Gentle 
June 29, 2017 at 9:17 AM
On Thu, Jun 29, 2017 at 8:49 AM, Jimmy McArthur  wrote:

Thierry Carrez wrote:

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.

If there is specifically confusion around Google searches, I'd suggest as a
first step to spend some time working on redirects for dead projects and
very clearly updating documentation. For all of Google's magic, there are
some simple and easy rules to help correct bad search data.


This.

Even though I've worked on the docs for years, I don't think we are
improving on this front.

Jimmy, do you know how to put more recent docs (instead of most
established docs) at the top of the search hits? The nature of the
algorithm rewards longevity over recency, and I've never quite learned
how to take care of that.
Longevity is one thing, as is relevance. If there are projects that are 
no longer maintained but still have "relevant" data under the o.o 
domain, they will come up in a Google search.  The trick is to make sure 
you're removing that data, not just putting a message at the top to the 
end user to say it's no longer an OpenStack project. In this specific 
example, I would create a new page like wiki.o.o/machine-learning with 
valid links to OpenStack docs on machine learning and do a 301 permanent 
redirect from pages that are no longer relevant (e.g. 
https://wiki.openstack.org/wiki/Meteos).


Are there other specific ideas you have?
The best way to tailor Google results is to ensure the sitemap is up to 
date (https://docs.openstack.org/sitemap.xml) and you are setting the 
proper  301, 302, and 404 responses.  If there is old data, it needs to 
be dealt with properly, which is a massive PITA, but completely worth 
it.  Search engines WILL follow the rules if you direct them properly.



Additionally, we just implemented SwifType on OpenStack.org and docs.o.o b/c
Google deprecated their Site Search product. We have a ton of control over
that search and can very easily modify search results.


Pretty sure we want to tackle the "Google is my front page to the
Internet" problem first, but this search change is also excellent and
helpful.
100% correct :)  Just wanted to mention it. Honestly, if you fix the 
Google problem, then you'll automatically fix the new SwifType search as 
well.


Anne


Let me know if I can be of service on any of these fronts.



__
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




Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 02:35 AM, Thierry Carrez wrote:

Sean McGinnis wrote:


The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not. If you google "openstack machine
learning", the first hits are Cognitive and Meteos, and it's impossible
to tell that those are actually not OpenStack projects. One of those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or community.


Maybe this is a bit of a tangent from the overall discussion, but
since a lot of confusion, and bad perception, can stem from dead
projects - as a first small step, could we move dead projects
out of openstack/* into closedstack/* and move or mark their wiki
to indicate it is just for legacy reference?


It's difficult to do. From a governance perspective, the "hosted" (or
"unofficial") space has no rules, so it's nobody's job (and right) to
clean things up. From a technical perspective, it's painful due to
Gerrit requiring restarts for every rename.

It's doable -- we'd have to create some governance for the "hosted"
space (creating a bit more confusion, since this was previously defined
as the "ungoverned" space), and add more to the infra team pile of work.

Anyway, that's part of "addressing the confusion at the edges" option.



Agree, it is doable - but is also work.

I also continue to challenge the assertion. There are dead projects in 
there for sure- but there are a LOT of non-dead live projects. It's not 
like we have 6 live and 6 dead projects. The overwhelming majority of 
the projects are not dead.


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> So I apologise if this has already been suggested/discussed (the
> long threads are difficult to keep up with), but has it been
> considered to go back to using a stackforge namespace?
[...]

Back in the bad ol' days when we had a separate namespace for
unofficial projects, it seemed to me like newcomers were just as
confused as they are now, perhaps even more so. People like to
forget, or wax nostalgic, or simply weren't around to see it first
hand back then; so I agree it's probably worth rehashing the pain
points as it's been a long time since I can recall anyone
enumerating them.

Gerrit's design assumes project names (including any prefixed
namespace) never change. This means project renames in Gerrit are
painful and disruptive (service outage for everyone, Git remote
changes for anyone working on that repo, risk of breaking things
with a SQL update query or directory move, et cetera). There is no
good automation for transfers between orgs in GH either so handling
this is a manual process involving lot of clicking around in a Web
browser. Project renames also touch other systems (our many Git
servers, StoryBoard) so more places to make mistakes or miss
something.

As a result, we would want to actively discourage repos moving from
the stackforge namespace into the openstack namespace (or vice
versa) which creates an artificial hurdle for projects seeking to
become official. This causes them to place an urgent pressure on the
Infra team which makes it harder for us to ease the pain of renames
by batching them up and processing them less frequently. We
similarly would no longer be allowed to create repos directly in the
openstack namespace without prior approval from the TC, which puts
the brakes on the current flow where teams can create a new repo as
quickly as the project-config-cores review the change and then work
on the corresponding governance addition in parallel with doing
their project development.

In the past the ability to push most of the work of doing renames
onto the Infra team created a perverse incentive for projects to
start unofficial so they didn't have to wait on the TC, and then ask
for a rename once they got approval rather than waiting to start
work until the TC approved their request. It's hard for the Infra
team to effectively deter that sort of behavior because the most we
can do is ask authors of their intentions and then trust that
they're being up front about a lack of interest in becoming official
(and that they're unlikely to change their minds about it later).

Unfortunately, hosting unofficial projects grants official teams a
license to experiment in that space rather than taking
responsibility up front, and this is detrimental to our community as
a whole. It also gives new teams an easy excuse to put off applying
to become official until later since they get most of the
infrastructure benefits right away regardless. If we could get rid
of this pervasive temptation to "incubate" ideas out from under the
shadow of governance then maybe that would make maintaining the rest
under a different namespace slightly less of a burden, as the need
to move repos between namespaces would then be far less common or
urgent.
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][tc] How to deal with confusion around "hosted projects"

[Anne Gentle]

On Thu, Jun 29, 2017 at 8:49 AM, Jimmy McArthur  wrote:
>
>
> Thierry Carrez wrote:
>>
>> The confusion I'm talking about is not the passive-aggressive from
>> people involved in openstack. It's from our prospective new users, who
>> have no idea about our governance, making random searches on Google.
>> It's from people getting hit by marketing message from projects claiming
>> to be official OpenStack projects, while they are not. It's extremely
>> difficult for those to see clearly, especially with all our online
>> presence reinforcing the confusion.
>
> If there is specifically confusion around Google searches, I'd suggest as a
> first step to spend some time working on redirects for dead projects and
> very clearly updating documentation. For all of Google's magic, there are
> some simple and easy rules to help correct bad search data.

This.

Even though I've worked on the docs for years, I don't think we are
improving on this front.

Jimmy, do you know how to put more recent docs (instead of most
established docs) at the top of the search hits? The nature of the
algorithm rewards longevity over recency, and I've never quite learned
how to take care of that.

Are there other specific ideas you have?

>
> Additionally, we just implemented SwifType on OpenStack.org and docs.o.o b/c
> Google deprecated their Site Search product. We have a ton of control over
> that search and can very easily modify search results.

Pretty sure we want to tackle the "Google is my front page to the
Internet" problem first, but this search change is also excellent and
helpful.

Anne

>
> Let me know if I can be of service on any of these fronts.
>
>
>
> __
> 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



-- 

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Thierry Carrez wrote:

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.
If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and docs.o.o 
b/c Google deprecated their Site Search product. We have a ton of 
control over that search and can very easily modify search results.


Let me know if I can be of service on any of these fronts.


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

Howdy,

So I apologise if this has already been suggested/discussed (the long
threads are difficult to keep up with), but has it been considered to go
back to using a stackforge namespace?

It seems to me that the role of stackforge to provide a proving ground or
place for aligned projects/repos was quite clear and well understood
(although perhaps I'm wrong). There were some technical challenges in
moving between namespaces that were less than ideal, but have we A)
investigated what would be required to overcome or at least lessen the
technical challenges, and/or B) weighed them against the alternatives and
current proposals?

Cheers,
Josh

On Thu, Jun 29, 2017 at 6:17 PM, Thierry Carrez 
wrote:

> James E. Blair wrote:
> > Thierry Carrez  writes:
> >
> >> Removing the root cause would be a more radical move: stop offering
> >> hosting to non-OpenStack projects on OpenStack infrastructure
> >> altogether. We originally did that for a reason, though. The benefits of
> >> offering that service are:
> >>
> >> 1- it lets us set up code repositories and testing infrastructure before
> >> a project applies to be an official OpenStack project.
> >>
> >> 2- it lets us host things that are not openstack but which we work on
> >> (like abandoned Python libraries or GPL-licensed things) in a familiar
> >> environment
> >>
> >> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> >
> > I think this omits what I consider the underlying reason for why we did
> > it:
> >
> > It helps us build a community around OpenStack.
> >
> > Early on we had so many people telling us that we needed to support
> > "ecosystem" projects better.  That was the word they used at the time.
> > Many of us said "hey, you're free to use github" and they told us that
> > wasn't enough.
> >
> > We eventually got the message and invited them in, and it surpassed our
> > expectations and I think surprised even the most optimistic of us.  We
> > ended up in a place where anyone with an OpenStack related idea can try
> > it out and collaborate frictionlessly with everyone else in the
> > OpenStack community on it, and in doing so, become recognized in the
> > community for that.  The ability for someone to build something on top
> > of OpenStack as part of the OpenStack community has been empowering.
> >
> > I confess to being a skeptic and a convert.  I wasn't thrilled about the
> > unbounded additional responsibility when we started this, but now that
> > we're here, I think it's one of the best things about the project and I
> > would hate to cleave our community by ending it.
>
> I think that's a great point, Jim.
>
> I spent a lot of time last week analyzing the "negative space" (things
> that are on our project infrastructure but are not openstack), and there
> are indeed a number of projects which would qualify as "companion
> projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
> for some proprietary hardware that got kicked out of the Neutron
> stadium. There aren't so many of those, but keeping those close to us is
> definitely a good thing.
>
> Ideally we would find a way to continue to host those, without creating
> any doubt as to whether they are an official OpenStack project under TC
> governance. Such options to address the confusion at the edge exist, and
> they were explored in the previous thread (selective GitHub replication,
> aggressive tagging, active removal of obviously-dead things, separate
> branding/domains...). The main issue being, those options all involved a
> lot of work for the infra team, work that is not conceivable with its
> current limited resources. The only reason why I put the nuclear plan B
> on the table is that we can't get the plan A properly done...
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

James E. Blair wrote:
> Thierry Carrez  writes:
> 
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>> 1- it lets us set up code repositories and testing infrastructure before
>> a project applies to be an official OpenStack project.
>>
>> 2- it lets us host things that are not openstack but which we work on
>> (like abandoned Python libraries or GPL-licensed things) in a familiar
>> environment
>>
>> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I think this omits what I consider the underlying reason for why we did
> it:
> 
> It helps us build a community around OpenStack.
> 
> Early on we had so many people telling us that we needed to support
> "ecosystem" projects better.  That was the word they used at the time.
> Many of us said "hey, you're free to use github" and they told us that
> wasn't enough.
> 
> We eventually got the message and invited them in, and it surpassed our
> expectations and I think surprised even the most optimistic of us.  We
> ended up in a place where anyone with an OpenStack related idea can try
> it out and collaborate frictionlessly with everyone else in the
> OpenStack community on it, and in doing so, become recognized in the
> community for that.  The ability for someone to build something on top
> of OpenStack as part of the OpenStack community has been empowering.
> 
> I confess to being a skeptic and a convert.  I wasn't thrilled about the
> unbounded additional responsibility when we started this, but now that
> we're here, I think it's one of the best things about the project and I
> would hate to cleave our community by ending it.

I think that's a great point, Jim.

I spent a lot of time last week analyzing the "negative space" (things
that are on our project infrastructure but are not openstack), and there
are indeed a number of projects which would qualify as "companion
projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
for some proprietary hardware that got kicked out of the Neutron
stadium. There aren't so many of those, but keeping those close to us is
definitely a good thing.

Ideally we would find a way to continue to host those, without creating
any doubt as to whether they are an official OpenStack project under TC
governance. Such options to address the confusion at the edge exist, and
they were explored in the previous thread (selective GitHub replication,
aggressive tagging, active removal of obviously-dead things, separate
branding/domains...). The main issue being, those options all involved a
lot of work for the infra team, work that is not conceivable with its
current limited resources. The only reason why I put the nuclear plan B
on the table is that we can't get the plan A properly done...

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Monty Taylor wrote:
> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>> [...] Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
> 
> I disagree that this is removing the root cause.
> 
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
> 
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It
> is suggested that the existence of git repos in the openstack/ github
> org is confusing to people. And our reaction to that is to cut off
> access to our Open Source tools that we set up to collaboratively
> develop cloud software and tell people to go use the thing that people
> suggest is one of the causes of people being confused?

I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.

> * People are not 'confused' by what OpenStack is.
> 
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going
> to be unhappy with cloudkitty, congress and karbor.
> 
> Such people are under the misguided impression that kicking cloudkitty
> out of OpenStack will somehow cause Nova features to land quicker. I
> can't even begin to express all of the ways in which it's wrong. We
> aren't a top-down corporate structure and we can't 'reassign' humans -
> but even if we WERE - this flawed thinking runs afoul of the Mythical
> Man Month.

Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.

> * Kicking non-official things out will not help
> 
> If I'm wrong about the above and it really is all just about not being
> able to navigate a set of repositories that are prefixed with the string
> 'openstack/', it STILL WON'T HELP.
> 
> There are 1049 official repos. There are only 1676 repos in gerrit.
> 
> Do we honestly think that people who are confused are going to be less
> confused by the number of repos in the sacred 'openstack/' namespace
> going from 1676 to 1049? Do we next tell projects they can only have
> their primary service managed? Kick out chef, puppet, juju and ansible,
> as well as the deb- repos? Because maybe the existence of
> openstack/deb-python-oslo.privsep is confusing someone?

Again, I agree, but I think you're missing my point. Kicking
non-official things is not about cutting the number of repositories, or
somehow making the git.openstack.org/cgit front page more navigable. We
are indeed past that.

Kicking non-official things is about stopping blurring the line between
what's "in" openstack and what's "out". It's about someone googling for
machine learning on openstack, finding Cognitive on git.openstack.org
and wiki.openstack.org, assuming it's an official openstack project
based on those domain names, trying to check it out, realizing it's only
4 commits and dead for two years, and assuming OpenStack has pretty low
standards and is a bunch of dead crap. How do you propose we address
*that* ?

> [...]
>> Thoughts on that ? Would you rather address the confusion at the edges,
>> or remove the root cause ?
> 
> The only reasonable action is actually addressing the confusion.
> 
> the confusion isn't just at the edges - the confusion is actually THE
> ONLY PROBLEM. There is no other problem that needs to be solved _other_
> than confusion in this area. The number of projects in gerrit is not a
> technical problem. 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Sean McGinnis wrote:
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
> 
> Maybe this is a bit of a tangent from the overall discussion, but
> since a lot of confusion, and bad perception, can stem from dead
> projects - as a first small step, could we move dead projects
> out of openstack/* into closedstack/* and move or mark their wiki
> to indicate it is just for legacy reference?

It's difficult to do. From a governance perspective, the "hosted" (or
"unofficial") space has no rules, so it's nobody's job (and right) to
clean things up. From a technical perspective, it's painful due to
Gerrit requiring restarts for every rename.

It's doable -- we'd have to create some governance for the "hosted"
space (creating a bit more confusion, since this was previously defined
as the "ungoverned" space), and add more to the infra team pile of work.

Anyway, that's part of "addressing the confusion at the edges" option.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Steven Dake]

On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor  wrote:

> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The thread went
>> in a lot of directions, including discussing GitHub mirroring strategy,
>> what makes projects want to be official, the need for returning to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we should stop
>> using it. The issue is, merely stopping using it won't be enough. We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even with the
>> expansive "are you one of us" definition. Arguably the most confusing
>> aspect is the "openstack/" prefix in the git repository name, which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue on the
>> edges, or you can treat the root cause. Neither of those options is
>> really an OpenStack  governance change (or "big tent" change) -- they
>> are more about what to do with things that are actually *not* in our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer when
>> things are not official. The thread above discussed a lot of potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
>> way to tag all projects on GitHub that are not official, or mirror them
>> to another organization, or stop mirroring them altogether. We could
>> remove the openstack/ prefix from all the projects we host. We could
>> actively mark all wiki pages that are not about an official project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>
> I disagree that this is removing the root cause.
>
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
>
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It is
> suggested that the existence of git repos in the openstack/ github org is
> confusing to people. And our reaction to that is to cut off access to our
> Open Source tools that we set up to collaboratively develop cloud software
> and tell people to go use the thing that people suggest is one of the
> causes of people being confused?
>
> * People are not 'confused' by what OpenStack is.
>
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going to
> be unhappy with cloudkitty, congress and karbor.
>

Monty,

I think you are right on the money on this second point although it is
missing a salient point.  There really are two problems here.

If we as a community disagree about the answer "What is OpenStack?" how
should we expect a Google search to answer this question for us?  Most
people that have been working on OpenStack for a long time might agree
there is a "common core" of projects that make up OpenStack.  I'll call
this as what you refer to as "OpenStack should only be an 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Sean McGinnis]

> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 

Maybe this is a bit of a tangent from the overall discussion, but
since a lot of confusion, and bad perception, can stem from dead
projects - as a first small step, could we move dead projects
out of openstack/* into closedstack/* and move or mark their wiki
to indicate it is just for legacy reference?


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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[David Moreau Simard]

On Wed, Jun 28, 2017 at 5:50 PM, Monty Taylor  wrote:
> Such people are under the misguided impression that kicking cloudkitty out
> of OpenStack will somehow cause Nova features to land quicker. I can't even
> begin to express all of the ways in which it's wrong.

So much this.
I wonder where this perception is coming from, but I've definitely
seen it around.
Perhaps most notably from Mr. Shuttleworth [1] ?

Kicking projects like Cloudkitty isn't going to make the developers
working on Cloudkitty magically start working on Nova, Cinder or
Keystone.

[1]: 
http://www.eweek.com/cloud/ubuntu-linux-founder-tells-openstack-to-focus-on-things-that-matter

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[David Moreau Simard]

Hi !

I thought my perspective might be valuable as the author of a project that
would likely end up being slashed: ARA [1].

In a nutshell, ARA provides easy and seamless Ansible reporting on playbook
runs.

It has nothing to do with OpenStack, to be honest: it doesn't require
OpenStack to run, it doesn't run on OpenStack.
We highlight that ARA is not an "official" OpenStack project in the
contributors' documentation [2].

But, it was born out of necessity inside the RDO community (call that the
extended OpenStack community, if you will) due to the vast amount of our
workloads that are driven by Ansible.

I like to draw a parallel between ARA and JJB [3] (Jenkins Job Builder) as
two tools that the OpenStack community develops and use without slapping
the OpenStack brand on them.
If we take a step back, would projects like Nodepool or Zuul also be
affected by this kind of cut ? Where do we draw the line ? Are they
OpenStack projects or not ?

For me, applying for ARA to be hosted as a "community" project [4], or what
would've been a "Stackforge" project long ago, was a completely logical
choice to me.

I could go and praise how the Gerrit workflow is vastly superior than
GitHub pull requests or that the Zuul-driven CI is completely awesome.
But... The truth is that I sincerely hoped it would help the project gain
exposure and credibility in order to drive adoption *inside* the OpenStack
community.

We say that hindsight is 20/20, but, in retrospect [5], I guess we could
say it worked.
Maybe out of luck, maybe out of sheer dedication and long weekends spent
working on the project.

The reality is that today, ARA is used by many different projects inside
the OpenStack ecosystem -- to name a few:
- OpenStack-Ansible
- TripleO
- Browbeat
- Kolla/Kolla-Ansible
- Devstack-Gate

But also, like Jenkins Job Builder, it has gained adoption outside of the
OpenStack community -- such as inside the OpenShift Ansible community or
BonnyCI.

Being part of the OpenStack "ecosystem" allows ARA to do things like easily
implement a gate job almost verbatim from OpenStack-Ansible [6] to make
sure that each new commit doesn't break them.
I feel that this is useful and powerful not just for ARA but for
OpenStack-Ansible and the other projects that use it as well.

Ironically, some projects feel hindered by this ecosystem (see: Gnocchi)
and have made an exit.
I do not share these feelings and I would in fact be very sad to be shown
the door.

My 0.02$CAD (not worth much right now)

​[1]​: https://github.com/openstack/ara
​[2]: ​http://ara.readthedocs.io/en/latest/contributing.html#contributing
[3]: https://github.com/openstack-infra/jenkins-job-builder
[4]: https://review.openstack.org/#/c/321226/
​[5]:
https://dmsimard.com/2017/05/08/ara-is-one-year-old-a-look-back-at-the-past-year/
​
​[6]:
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ara.yaml#L21-L89
​

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Jun 28, 2017 6:46 PM, "James E. Blair"  wrote:

Thierry Carrez  writes:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
>
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I think this omits what I consider the underlying reason for why we did
it:

It helps us build a community around OpenStack.

Early on we had so many people telling us that we needed to support
"ecosystem" projects better.  That was the word they used at the time.
Many of us said "hey, you're free to use github" and they told us that
wasn't enough.

We eventually got the message and invited them in, and it surpassed our
expectations and I think surprised even the most optimistic of us.  We
ended up in a place where anyone with an OpenStack related idea can try
it out and collaborate frictionlessly with everyone else in the
OpenStack community on it, and in doing so, become recognized in the
community for that.  The ability for someone to build something on top
of OpenStack as part of the OpenStack community has been empowering.

I confess to being a skeptic and a convert.  I wasn't thrilled about the
unbounded additional responsibility when we started this, but now that
we're here, I think it's one of the best things about the project and I
would hate to cleave our community by ending it.

-Jim

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[James E. Blair]

Thierry Carrez  writes:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
>
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself

I think this omits what I consider the underlying reason for why we did
it:

It helps us build a community around OpenStack.

Early on we had so many people telling us that we needed to support
"ecosystem" projects better.  That was the word they used at the time.
Many of us said "hey, you're free to use github" and they told us that
wasn't enough.

We eventually got the message and invited them in, and it surpassed our
expectations and I think surprised even the most optimistic of us.  We
ended up in a place where anyone with an OpenStack related idea can try
it out and collaborate frictionlessly with everyone else in the
OpenStack community on it, and in doing so, become recognized in the
community for that.  The ability for someone to build something on top
of OpenStack as part of the OpenStack community has been empowering.

I confess to being a skeptic and a convert.  I wasn't thrilled about the
unbounded additional responsibility when we started this, but now that
we're here, I think it's one of the best things about the project and I
would hate to cleave our community by ending it.

-Jim

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

Hi everyone,

Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The thread went
in a lot of directions, including discussing GitHub mirroring strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html

Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.

The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not. If you google "openstack machine
learning", the first hits are Cognitive and Meteos, and it's impossible
to tell that those are actually not OpenStack projects. One of those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or community.

The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even with the
expansive "are you one of us" definition. Arguably the most confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.

I'd say we have two options. We can address the perception issue on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack  governance change (or "big tent" change) -- they
are more about what to do with things that are actually *not* in our
governance.

Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could find a
way to tag all projects on GitHub that are not official, or mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is that it's
a *lot* of work, and it never completely eliminates the confusion.

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do 
not believe that doing this provides any value to us as a community.


Even though we do not actually use github for development, we have 
implicitly accepted the false premise that github is a requirement. It 
is suggested that the existence of git repos in the openstack/ github 
org is confusing to people. And our reaction to that is to cut off 
access to our Open Source tools that we set up to collaboratively 
develop cloud software and tell people to go use the thing that people 
suggest is one of the causes of people being confused?


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they 
DISAGREE with what OpenStack is. We still have _plenty_ of people who 
express that they think we should only be IaaS - so they're still going 
to be unhappy with cloudkitty, congress and karbor.


Such people are under the misguided impression that kicking cloudkitty 
out of OpenStack will somehow cause Nova features to land quicker. I 
can't even begin to express all of the ways in which it's wrong. We 
aren't a top-down corporate structure and we can't 'reassign' humans - 
but even if we WERE - this flawed thinking runs afoul of the Mythical 
Man Month.


* Kicking non-official things out will not help

If I'm wrong about the above and it really is all just about not being 
able to navigate a set of repositories that are prefixed with the string 
'openstack/', it STILL WON'T HELP.


There are 1049 official repos. There are only 1676 repos in gerrit.

Do we honestly think that people who are confused are going to be less 
confused by the number 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 01:48 PM, Clay Gerrard wrote:



On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez > wrote:



2- it lets us host things that are not openstack but which we work on
(like abandoned Python libraries or GPL-licensed things) in a familiar
environment


Do we no longer think openstack hosted infra holds a competitive 
advantage for teams that are trying to efficiently collaborate building 
software in service of the mission?


I think it absolutely does.

If we do, why would we agree on a plan that basically tells teams that 
are trying to "get stuff done" to go work it out on github and travis ci 
or whatever?  Maybe worse, what happens when a team/project/community 
grows up around *one* workflow (not because it's better; but just 
because the OpenStack workflow is exclusionary) but then it sees it's 
operators/deployers/users adoption swelling around OpenStack and wants 
to "join"?  Is adopting the hosted infrastructure later... optional?


++ to these questions

This is the reason I do not think we should stop hosting 'non-official' 
software. There are many things we have that allow for collaboration 
across individual project domains that we have developed over time 
exactly to address all of these issues. They may not always fit everyone 
perfect, but they provide enough value that our problem is currently 
that "too many people" want to collaborate directly, rather than that 
our tooling is driving people away.


If we do NOT think hosting on openstack-infra offers competitive 
advantage for teams that are trying to efficiently collaborate building 
software in service of the mission ... why heck not?!


-Clay


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




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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Clay Gerrard]

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez 
wrote:

> It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not.


Just an aside, this Perception problems works in our favor sometimes too.
I know in the past some BigCorp contributors have been told to "go work on
OpenStack" and the ambiguity leaves room for creative allocation of
resources.  Sometimes the rule-of-thumb is as simple as "if it's hosted on
OpenStack infra you can contribute".  I think internally we understand
software in service of the mission isn't strictly limited to projects under
TC governance - but on the outside ... there's a "perception problem" ;)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Clay Gerrard]

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez 
wrote:

>
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
>
>
Do we no longer think openstack hosted infra holds a competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission?

If we do, why would we agree on a plan that basically tells teams that are
trying to "get stuff done" to go work it out on github and travis ci or
whatever?  Maybe worse, what happens when a team/project/community grows up
around *one* workflow (not because it's better; but just because the
OpenStack workflow is exclusionary) but then it sees it's
operators/deployers/users adoption swelling around OpenStack and wants to
"join"?  Is adopting the hosted infrastructure later... optional?

If we do NOT think hosting on openstack-infra offers competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission ... why heck not?!

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jay Pipes]

On 06/28/2017 01:07 PM, Clint Byrum wrote:

The root cause of all of this until now has been not really knowing what
OpenStack is. The visioning recently done was a great step in the right
direction toward this. I would like to make sure that we acknowledge
this while we address symptoms of the past choices we made.

In particular, I wonder if landing the vision, pushing harder to fill
in any missing parts of the constellation concept, and getting actual
constellations defined _immediately_, would do just as much as drawing
these concerte lines around abstract bits of software.


So much this.

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] [all][tc] How to deal with confusion around "hosted projects"

[Clint Byrum]

This message makes a bunch of salient, valid points, none of which I
wish to directly address.

However, on the whole, I think the analysis stops short of pushing through
to a root cause, and thus, the solution proposed is entirely focused on
symptoms.

The root cause of all of this until now has been not really knowing what
OpenStack is. The visioning recently done was a great step in the right
direction toward this. I would like to make sure that we acknowledge
this while we address symptoms of the past choices we made.

In particular, I wonder if landing the vision, pushing harder to fill
in any missing parts of the constellation concept, and getting actual
constellations defined _immediately_, would do just as much as drawing
these concerte lines around abstract bits of software.

So, I'm not saying any of this is wrong. I like the solution proposed,
and I think all of the problems stated are in fact problems. I just
wonder if we're bouncing off "visions are hard" and falling into a bit
of yak shaving around the easy problems when we as a community should
remain focused on the vision.

If nothing else, I'd like to see it clearly stated how this solution
fits in with the vision.

Excerpts from Thierry Carrez's message of 2017-06-28 16:50:01 +0200:
> Hi everyone,
> 
> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
> working on "better communicating what is openstack", I started a
> thread[1] about moving away from big tent terminology. The thread went
> in a lot of directions, including discussing GitHub mirroring strategy,
> what makes projects want to be official, the need for returning to a
> past when everything was (supposedly) simpler, and naming fun.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
> 
> Many agreed that the "Big Tent" name (as a synonym to "official
> openstack projects") is hurting more than it helps, and we should stop
> using it. The issue is, merely stopping using it won't be enough. We
> have tried, and the name sticks. You need to replace the name by
> something that sticks more, or address the root cause directly.
> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 
> The confusion mainly stems from the fact that OpenStack project
> infrastructure is open to any open source project (and it's nobody's job
> to clean up dead things). So you can find (on our wiki, on our
> mailing-list, on our cgit farm, on our gerrit, on our GitHub
> organization...) things that are actually not OpenStack, even with the
> expansive "are you one of us" definition. Arguably the most confusing
> aspect is the "openstack/" prefix in the git repository name, which
> indicates some kind of brand association.
> 
> I'd say we have two options. We can address the perception issue on the
> edges, or you can treat the root cause. Neither of those options is
> really an OpenStack  governance change (or "big tent" change) -- they
> are more about what to do with things that are actually *not* in our
> governance.
> 
> Addressing the perception on the edges means making it clearer when
> things are not official. The thread above discussed a lot of potential
> solutions. We could give unofficial things a catchy group name
> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
> way to tag all projects on GitHub that are not official, or mirror them
> to another organization, or stop mirroring them altogether. We could
> remove the openstack/ prefix from all the projects we host. We could
> actively mark all wiki pages that are not about an official project. We
> could set up a separate Gerrit or separate ML for hosted projects
> development discussions. The main issue with that approach is that it's
> a *lot* of work, and it never completely eliminates the confusion.
> 
> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
> 
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
> 
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
> 
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I would argue that we could handle 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Anita Kuno wrote:
> On 2017-06-28 10:50 AM, Thierry Carrez wrote:
>> For (1) we could have an "onboarding" project team that would help
>> incoming projects through the initial steps of becoming an openstack
>> project. The team would act as an umbrella team, an experimental area
>> for projects that have some potential to become an OpenStack project one
>> day. There would be a time limit -- if after one year(?) it looks like
>> you won't become an openstack project after all, the onboarding team
>> would clean you up. I actually think a bit more project mentoring would
>> serve us better than our current hands-free approach.
> Who is going to staff this team?
> 
> I think a large reason that we are in the situation we are in is due to
> the fact that large corp can't see the importance of paying salaries for
> people to help others and keep things clean and tidy. They will foot the
> bill for building the thing, they tend to be reluctant to pay to keep
> things tidy and well maintained.
> 
> I'm not saying it isn't a good idea. I felt the work was very valuable
> when I did it and I thought the community appreciated it a lot. But for
> the last year I have not had the benefit of an employer who feels there
> is enough value in this approach to pay my salary to do the work.
> 
> Would be glad to be proven wrong.

At the TC level, we started to try to pair prospective teams with
mentors to help them through. I'm pretty sure current and past
volunteers on this task would be happy to help and seed that team.

It's not that much work, and it's work we end up doing anyway (questions
always get asked, they just get asked at awkward times in the
application process).

Currently the first contact we get is when a project team applies to
become an official project (which invariably comes too early). Engaging
earlier with a team of mentors sounds like it would save us a lot of
problems down the line, and clear out a lot of confusion with the process.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Anita Kuno]

On 2017-06-28 10:50 AM, Thierry Carrez wrote:

For (1) we could have an "onboarding" project team that would help
incoming projects through the initial steps of becoming an openstack
project. The team would act as an umbrella team, an experimental area
for projects that have some potential to become an OpenStack project one
day. There would be a time limit -- if after one year(?) it looks like
you won't become an openstack project after all, the onboarding team
would clean you up. I actually think a bit more project mentoring would
serve us better than our current hands-free approach.

Who is going to staff this team?

I think a large reason that we are in the situation we are in is due to 
the fact that large corp can't see the importance of paying salaries for 
people to help others and keep things clean and tidy. They will foot the 
bill for building the thing, they tend to be reluctant to pay to keep 
things tidy and well maintained.


I'm not saying it isn't a good idea. I felt the work was very valuable 
when I did it and I thought the community appreciated it a lot. But for 
the last year I have not had the benefit of an employer who feels there 
is enough value in this approach to pay my salary to do the work.


Would be glad to be proven wrong.

Thanks,
Anita.

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Neil Jerram]

On Wed, Jun 28, 2017 at 3:50 PM Thierry Carrez 
wrote:

> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. [...]


I think this is the right solution for OpenStack.  In particular, I think
it will clarify external perception, and will promote internal focus on
developing integration between the remaining projects that _are_ OpenStack.

I say that even as maintainer of one of the hosted non-official projects
(networking-calico) that would be booted out under this proposal.  I will
have a bit of work to do to set up equivalent CI that I currently get from
the OpenStack infrastructure - but that will have fringe benefits too, in
terms of my team's ability to change things more rapidly.  I'm grateful for
the experience and mentoring that I've had while using the OpenStack
infrastructure - that makes me feel confident that I can now set up what
networking-calico needs myself.

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-06-28 16:50:01 +0200:
> Hi everyone,
> 
> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
> working on "better communicating what is openstack", I started a
> thread[1] about moving away from big tent terminology. The thread went
> in a lot of directions, including discussing GitHub mirroring strategy,
> what makes projects want to be official, the need for returning to a
> past when everything was (supposedly) simpler, and naming fun.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
> 
> Many agreed that the "Big Tent" name (as a synonym to "official
> openstack projects") is hurting more than it helps, and we should stop
> using it. The issue is, merely stopping using it won't be enough. We
> have tried, and the name sticks. You need to replace the name by
> something that sticks more, or address the root cause directly.
> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 
> The confusion mainly stems from the fact that OpenStack project
> infrastructure is open to any open source project (and it's nobody's job
> to clean up dead things). So you can find (on our wiki, on our
> mailing-list, on our cgit farm, on our gerrit, on our GitHub
> organization...) things that are actually not OpenStack, even with the
> expansive "are you one of us" definition. Arguably the most confusing
> aspect is the "openstack/" prefix in the git repository name, which
> indicates some kind of brand association.
> 
> I'd say we have two options. We can address the perception issue on the
> edges, or you can treat the root cause. Neither of those options is
> really an OpenStack  governance change (or "big tent" change) -- they
> are more about what to do with things that are actually *not* in our
> governance.
> 
> Addressing the perception on the edges means making it clearer when
> things are not official. The thread above discussed a lot of potential
> solutions. We could give unofficial things a catchy group name
> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
> way to tag all projects on GitHub that are not official, or mirror them
> to another organization, or stop mirroring them altogether. We could
> remove the openstack/ prefix from all the projects we host. We could
> actively mark all wiki pages that are not about an official project. We
> could set up a separate Gerrit or separate ML for hosted projects
> development discussions. The main issue with that approach is that it's
> a *lot* of work, and it never completely eliminates the confusion.
> 
> Removing the root cause would be a more radical move: stop offering
> hosting to non-OpenStack projects on OpenStack infrastructure
> altogether. We originally did that for a reason, though. The benefits of
> offering that service are:
> 
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
> 
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
> 
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I would argue that we could handle (1) and (2) within our current
> governance.
> 
> For (1) we could have an "onboarding" project team that would help
> incoming projects through the initial steps of becoming an openstack
> project. The team would act as an umbrella team, an experimental area
> for projects that have some potential to become an OpenStack project one
> day. There would be a time limit -- if after one year(?) it looks like
> you won't become an openstack project after all, the onboarding team
> would clean you up. I actually think a bit more project mentoring would
> serve us better than our current hands-free approach.
> 
> For (2) we could also have some other official project team as an
> umbrella for those deps we depend on and have to continue maintaining.
> Or we could expand Oslo's team scope to cover it. It's just a couple of
> repositories anyway.
> 
> That leaves (3). I would argue that was a nice thing to have, but its
> impact was very limited (not so many successful/alive projects in that
> category). I guess if the need is still there and people really want to
> work on this, it could be (and actually has been) set up as a parallel
> infrastructure. The confusion that stems from running it