Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

[Davanum Srinivas]

Josh,

The Kata team is talking to QEMU maintainers about how best to move
forward. Specially around stripping down things that's not needed for
their use case. They are not adding code from what i got to know (just
removing stuff).

-- Dims

On Fri, Jun 1, 2018 at 12:12 PM, Joshua Harlow  wrote:
> Slightly off topic but,
>
> Have you by any chance looked at what kata has forked for qemu:
>
> https://github.com/kata-containers/qemu/tree/qemu-lite-2.11.0
>
> I'd be interested in an audit of that code for similar reasons to this
> libvirt fork (hard to know from my view point if there are new issues in
> that code like the ones you are finding in libvirt).
>
> Kashyap Chamarthy wrote:
>>
>> On Tue, May 22, 2018 at 01:54:59PM -0500, Dean Troyer wrote:
>>>
>>> StarlingX (aka STX) was announced this week at the summit, there is a
>>> PR to create project repos in Gerrit at [0]. STX is basically Wind
>>
>>
>>  From a cursory look at the libvirt fork, there are some questionable
>> choices.  E.g. the config code (libvirt/src/qemu/qemu.conf) is modified
>> such that QEMU is launched as 'root'.  That means a bug in QEMU ==
>> instant host compromise.
>>
>> All Linux distributions (that matter) configure libvirt to launch QEMU
>> as a regular user ('qemu').  E.g. from Fedora's libvirt RPM spec file:
>>
>>  libvirt.spec:%define qemu_user  qemu
>>  libvirt.spec:   --with-qemu-user=%{qemu_user} \
>>
>>  * * *
>>
>> There are multiple other such issues in the forked libvirt code.
>>
>> [...]
>>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [StarlingX] StarlingX code followup discussions

[Joshua Harlow]

Slightly off topic but,

Have you by any chance looked at what kata has forked for qemu:

https://github.com/kata-containers/qemu/tree/qemu-lite-2.11.0

I'd be interested in an audit of that code for similar reasons to this 
libvirt fork (hard to know from my view point if there are new issues in 
that code like the ones you are finding in libvirt).


Kashyap Chamarthy wrote:

On Tue, May 22, 2018 at 01:54:59PM -0500, Dean Troyer wrote:

StarlingX (aka STX) was announced this week at the summit, there is a
PR to create project repos in Gerrit at [0]. STX is basically Wind


 From a cursory look at the libvirt fork, there are some questionable
choices.  E.g. the config code (libvirt/src/qemu/qemu.conf) is modified
such that QEMU is launched as 'root'.  That means a bug in QEMU ==
instant host compromise.

All Linux distributions (that matter) configure libvirt to launch QEMU
as a regular user ('qemu').  E.g. from Fedora's libvirt RPM spec file:

 libvirt.spec:%define qemu_user  qemu
 libvirt.spec:   --with-qemu-user=%{qemu_user} \

 * * *

There are multiple other such issues in the forked libvirt code.

[...]



__
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] [StarlingX] StarlingX code followup discussions

[Kashyap Chamarthy]

On Tue, May 22, 2018 at 01:54:59PM -0500, Dean Troyer wrote:
> StarlingX (aka STX) was announced this week at the summit, there is a
> PR to create project repos in Gerrit at [0]. STX is basically Wind

From a cursory look at the libvirt fork, there are some questionable
choices.  E.g. the config code (libvirt/src/qemu/qemu.conf) is modified
such that QEMU is launched as 'root'.  That means a bug in QEMU ==
instant host compromise.

All Linux distributions (that matter) configure libvirt to launch QEMU
as a regular user ('qemu').  E.g. from Fedora's libvirt RPM spec file:

libvirt.spec:%define qemu_user  qemu
libvirt.spec:   --with-qemu-user=%{qemu_user} \

* * *

There are multiple other such issues in the forked libvirt code.

[...]

-- 
/kashyap

__
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] [StarlingX] StarlingX code followup discussions

[Kashyap Chamarthy]

On Tue, May 22, 2018 at 05:41:18PM -0400, Brian Haley wrote:
> On 05/22/2018 04:57 PM, Jay Pipes wrote:

[...]

> > Please don't take this the wrong way, Dean, but you aren't seriously
> > suggesting that anyone outside of Windriver/Intel would ever contribute
> > to these repos are you?
> > 
> > What motivation would anyone outside of Windriver/Intel -- who must make
> > money on this effort otherwise I have no idea why they are doing it --
> > have to commit any code at all to StarlingX?

Yes, same question as Jay here.

What this product-turned-project (i.e. "Downstream First") is implicitly
asking for is the review time of the upstream community, which is
already at a premium -- for a fork.

> I read this the other way - the goal is to get all the forked code from
> StarlingX into upstream repos.  That seems backwards from how this should
> have been done (i.e. upstream first), and I don't see how a project would
> prioritize that over other work.
> 
> > I'm truly wondering why was this even open-sourced to begin with? I'm as
> > big a supporter of open source as anyone, but I'm really struggling to
> > comprehend the business, technical, or marketing decisions behind this
> > action. Please help me understand. What am I missing?
> 
> I'm just as confused.

Equally stupefied here.

> > My personal opinion is that I don't think that any products, derivatives
> > or distributions should be hosted on openstack.org infrastructure.

Yes, it should be unmistakably clear that contributions to "upstream
Nova", for example, means the 'primary' (this qualifier itself is
redundant) upstream Nova.  No slippery slope such as: "OpenStack-hosted
Nova, but not exactly _that_ OpenStack Nova".

-- 
/kashyap

__
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] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

On Thu, May 24, 2018 at 11:23 PM, Tim Bell  wrote:
> I'd like to understand the phrase "StarlingX is an OpenStack Foundation Edge 
> focus area project".
>
> My understanding of the current situation is that "StarlingX would like to be 
> OpenStack Foundation Edge focus area project".
>
> I have not been able to keep up with all of the discussions so I'd be happy 
> for further URLs to help me understand the current situation and the 
> processes (formal/informal) to arrive at this conclusion.

Agreed Tim, my apologies for being quick on the conclusions there.
Even after some discussions yesterday it is not clear to me exactly
the right phrasing.  I understand that the intention is to become an
incubated edge project, I do not know at what point StarlingX nor
Airship exactly are at today.

dt

-- 

Dean Troyer
dtro...@gmail.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] [StarlingX] StarlingX code followup discussions

[Tim Bell]

I'd like to understand the phrase "StarlingX is an OpenStack Foundation Edge 
focus area project".

My understanding of the current situation is that "StarlingX would like to be 
OpenStack Foundation Edge focus area project".

I have not been able to keep up with all of the discussions so I'd be happy for 
further URLs to help me understand the current situation and the processes 
(formal/informal) to arrive at this conclusion.

Tim

-Original Message-
From: Dean Troyer <dtro...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 23 May 2018 at 11:08
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

On Wed, May 23, 2018 at 11:49 AM, Colleen Murphy <coll...@gazlene.net> 
wrote:
> It's also important to make the distinction between hosting something on 
openstack.org infrastructure and recognizing it in an official capacity. 
StarlingX is seeking both, but in my opinion the code hosting is not the 
problem here.

StarlingX is an OpenStack Foundation Edge focus area project and is
seeking to use the CI infrastructure.  There may be a project or two
contained within that may make sense as OpenStack projects in the
not-called-big-tent-anymore sense but that is not on the table, there
is a lot of work to digest before we could even consider that.  Is
that the official capacity you are talking about?

dt

-- 

Dean Troyer
dtro...@gmail.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


__
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] [StarlingX] StarlingX code followup discussions

[Dan Smith]

> For example, I look at your nova fork and it has a "don't allow this
> call during an upgrade" decorator on many API calls. Why wasn't that
> done upstream? It doesn't seem overly controversial, so it would be
> useful to understand the reasoning for that change.

Interesting. We have internal accounting for service versions and can
make a determination of if we're in an upgrade scenario (and do block
operations until the upgrade is over). Unless this decorator you're
looking at checks some non-upstream is-during-upgrade flag, this would
be an easy thing to close the gap on.

--Dan

__
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] [StarlingX] StarlingX code followup discussions

[Zane Bitter]

On 23/05/18 11:25, Dean Troyer wrote:

On Wed, May 23, 2018 at 12:58 PM, Julia Kreger
 wrote:

There is definitely value to be gained for both projects in terms of a
different point of view that might not have been able to play out in


Ironic is a bit different in this regard to the released code since
there _is_ overlap with the STX Bare Metal service.  There is also
not-overlapping aspects to it.  I would like to talk with you and the
Ironic team at some point about scope and goals for the long term.


the public community, but since we're dealing with squashed commits of
changes, it is really hard for us to delineate history/origin of code
fragments, and without that it makes it near impossible for projects
to even help them reconcile their technical debt because of that and
the lacking context surrounding that. It would be so much more
friendly to the community if we had stacks of patch files that we
could work with git.


+1


Unfortunately it was a requirement to not release the history.  There
are some bits that we were not allowed to release (for legal reasons,
not open core reasons) that are present in the history.  And yes it is
in most cases unusable to do anything more than browse for pulling
things upstream.


'git filter-branch' is your friend :)


What I did manage to get was permission to publish the individual
commits on top of the upstream base that do not run afoul of the legal
issues.  Given that this is all against Pike and we need to propose to
master first, they are not likely directly usable but the information
needed for the upstream work will be available.  These have not been
cleaned up yet but I plan to add them directly to the repos containing
the squashes as they are done.


Can I add myself to the list of confused people wanting to understand
better? I can see and understand value, but context and understanding
as to why as I mentioned above is going to be the main limiter for
interaction.


I have heard multiple reasons why this has been done, this is one area
I am not going to go into detail about other than the stuff that has
been cleared and released.  Understanding (some) business decisions
are not one of my strengths.

I will say that my opinion from working with WRS for a few months is
they do truly want to form a community around StarlingX and will be
moving their ongoing Titanium development there.

dt




__
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] [StarlingX] StarlingX code followup discussions

[Michael Still]

I think a good start would be a concrete list of the places you felt you
needed to change upstream and the specific reasons for each that it wasn't
done as part of the community.

For example, I look at your nova fork and it has a "don't allow this call
during an upgrade" decorator on many API calls. Why wasn't that done
upstream? It doesn't seem overly controversial, so it would be useful to
understand the reasoning for that change.

To be blunt I had a quick scan of the Nova fork and I don't see much of
interest there, but its hard to tell given how things are laid out now.
Hence the request for a list.

Michael




On Thu, May 24, 2018 at 6:36 AM, Dean Troyer  wrote:

> On Wed, May 23, 2018 at 2:20 PM, Brian Haley  wrote:
> > Even doing that is work - going through changes, finding nuggets,
> proposing
> > new specs I don't think we can expect a project to even go there, it
> has
> > to be driven by someone already involved in StarlingX, IMHO.
>
> In the beginning at least it will be.  We have prioritized lists for
> where we want to start.  Once I get the list and commits cleaned up
> everyone can look at them and weigh in on our starting point.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.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
>



-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
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] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

On Wed, May 23, 2018 at 2:20 PM, Brian Haley  wrote:
> Even doing that is work - going through changes, finding nuggets, proposing
> new specs I don't think we can expect a project to even go there, it has
> to be driven by someone already involved in StarlingX, IMHO.

In the beginning at least it will be.  We have prioritized lists for
where we want to start.  Once I get the list and commits cleaned up
everyone can look at them and weigh in on our starting point.

dt

-- 

Dean Troyer
dtro...@gmail.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] [StarlingX] StarlingX code followup discussions

[Jeremy Stanley]

On 2018-05-23 15:20:28 -0400 (-0400), Brian Haley wrote:
> On 05/23/2018 02:00 PM, Jeremy Stanley wrote:
> > On 2018-05-22 17:41:18 -0400 (-0400), Brian Haley wrote:
> > [...]
> > > I read this the other way - the goal is to get all the forked code from
> > > StarlingX into upstream repos.  That seems backwards from how this should
> > > have been done (i.e. upstream first), and I don't see how a project would
> > > prioritize that over other work.
> > [...]
> > 
> > I have yet to see anyone suggest it should be prioritized over other
> > work. I expect the extracted and proposed changes/specs
> > corresponding to the divergence would be viewed on their own merits
> > just like any other change and ignored, reviewed, rejected, et
> > cetera as appropriate.
> 
> Even doing that is work - going through changes, finding nuggets,
> proposing new specs I don't think we can expect a project to
> even go there, it has to be driven by someone already involved in
> StarlingX, IMHO.

I gather that's the proposal at hand. The StarlingX development team
would do the work to write specs for these feature additions,
propose them through the usual processes, then start extracting the
relevant parts of their "technical debt" corresponding to any specs
which get approved and propose patches to those services for review.
If they don't, then I agree this will go nowhere.
-- 
Jeremy Stanley


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] [StarlingX] StarlingX code followup discussions

[Brian Haley]

On 05/23/2018 02:00 PM, Jeremy Stanley wrote:

On 2018-05-22 17:41:18 -0400 (-0400), Brian Haley wrote:
[...]

I read this the other way - the goal is to get all the forked code from
StarlingX into upstream repos.  That seems backwards from how this should
have been done (i.e. upstream first), and I don't see how a project would
prioritize that over other work.

[...]

I have yet to see anyone suggest it should be prioritized over other
work. I expect the extracted and proposed changes/specs
corresponding to the divergence would be viewed on their own merits
just like any other change and ignored, reviewed, rejected, et
cetera as appropriate.


Even doing that is work - going through changes, finding nuggets, 
proposing new specs I don't think we can expect a project to even go 
there, it has to be driven by someone already involved in StarlingX, IMHO.


-Brian

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

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

[Colleen Murphy]

On Wed, May 23, 2018, at 8:07 PM, Dean Troyer wrote:
> On Wed, May 23, 2018 at 11:49 AM, Colleen Murphy  wrote:
> > It's also important to make the distinction between hosting something on 
> > openstack.org infrastructure and recognizing it in an official capacity. 
> > StarlingX is seeking both, but in my opinion the code hosting is not the 
> > problem here.
> 
> StarlingX is an OpenStack Foundation Edge focus area project and is
> seeking to use the CI infrastructure.  There may be a project or two
> contained within that may make sense as OpenStack projects in the
> not-called-big-tent-anymore sense but that is not on the table, there
> is a lot of work to digest before we could even consider that.  Is
> that the official capacity you are talking about?

I was talking about it being recognized by the OpenStack Foundation as part of 
one of its strategic focus areas. I understand StarlingX isn't seeking official 
recognition within the OpenStack project under the TC's governance.

Colleen

__
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] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

On Wed, May 23, 2018 at 1:24 PM, Matt Riedemann  wrote:
> Rather than literally making this a priority, I expect most of the feeling
> is that because of the politics and pressure of competition with a fork in
> another foundation is driving the defensiveness about feeling pressured to
> prioritize review on whatever specs/patches are proposed as a result of the
> code dump.

David Letterman used to say "This is not a competition it is just an
exhibition.  No wagering!"  for Stupid Pet Tricks.

The feelings that is is a competition is one aspect that I want to
help ease if I can.  Once we have the list of individual
upstream-desired changes we can talk about priorities (we do have a
priority list internally) and desirability.

The targeted use cases for StarlingX/Titanium has requirements that do
not fit other use cases or may not be widely useful.  We need to
figure out how to handle those in the long term.

dt

-- 

Dean Troyer
dtro...@gmail.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] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

On Wed, May 23, 2018 at 12:58 PM, Julia Kreger
 wrote:
> There is definitely value to be gained for both projects in terms of a
> different point of view that might not have been able to play out in

Ironic is a bit different in this regard to the released code since
there _is_ overlap with the STX Bare Metal service.  There is also
not-overlapping aspects to it.  I would like to talk with you and the
Ironic team at some point about scope and goals for the long term.

> the public community, but since we're dealing with squashed commits of
> changes, it is really hard for us to delineate history/origin of code
> fragments, and without that it makes it near impossible for projects
> to even help them reconcile their technical debt because of that and
> the lacking context surrounding that. It would be so much more
> friendly to the community if we had stacks of patch files that we
> could work with git.

Unfortunately it was a requirement to not release the history.  There
are some bits that we were not allowed to release (for legal reasons,
not open core reasons) that are present in the history.  And yes it is
in most cases unusable to do anything more than browse for pulling
things upstream.

What I did manage to get was permission to publish the individual
commits on top of the upstream base that do not run afoul of the legal
issues.  Given that this is all against Pike and we need to propose to
master first, they are not likely directly usable but the information
needed for the upstream work will be available.  These have not been
cleaned up yet but I plan to add them directly to the repos containing
the squashes as they are done.

> Can I add myself to the list of confused people wanting to understand
> better? I can see and understand value, but context and understanding
> as to why as I mentioned above is going to be the main limiter for
> interaction.

I have heard multiple reasons why this has been done, this is one area
I am not going to go into detail about other than the stuff that has
been cleared and released.  Understanding (some) business decisions
are not one of my strengths.

I will say that my opinion from working with WRS for a few months is
they do truly want to form a community around StarlingX and will be
moving their ongoing Titanium development there.

dt

-- 

Dean Troyer
dtro...@gmail.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] [StarlingX] StarlingX code followup discussions

[Matt Riedemann]

On 5/23/2018 11:00 AM, Jeremy Stanley wrote:

I have yet to see anyone suggest it should be prioritized over other
work. I expect the extracted and proposed changes/specs
corresponding to the divergence would be viewed on their own merits
just like any other change and ignored, reviewed, rejected, et
cetera as appropriate.


Rather than literally making this a priority, I expect most of the 
feeling is that because of the politics and pressure of competition with 
a fork in another foundation is driving the defensiveness about feeling 
pressured to prioritize review on whatever specs/patches are proposed as 
a result of the code dump.


--

Thanks,

Matt

__
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] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

On Wed, May 23, 2018 at 11:49 AM, Colleen Murphy  wrote:
> It's also important to make the distinction between hosting something on 
> openstack.org infrastructure and recognizing it in an official capacity. 
> StarlingX is seeking both, but in my opinion the code hosting is not the 
> problem here.

StarlingX is an OpenStack Foundation Edge focus area project and is
seeking to use the CI infrastructure.  There may be a project or two
contained within that may make sense as OpenStack projects in the
not-called-big-tent-anymore sense but that is not on the table, there
is a lot of work to digest before we could even consider that.  Is
that the official capacity you are talking about?

dt

-- 

Dean Troyer
dtro...@gmail.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] [StarlingX] StarlingX code followup discussions

[Jeremy Stanley]

On 2018-05-23 13:48:56 -0400 (-0400), Jay Pipes wrote:
[...]
> I believe you may be confusing packages (or package specs) with
> distributions?
> 
> Mirantis OpenStack was never hosted on an openstack
> infrastructure. Fuel is, as are deb spec files and Puppet
> manifests, etc. But the distribution of OpenStack is the
> collection of all those specs/build files along with a default
> configuration and things like project deltas exposed as patch
> files. Same goes for RDO, Canonical OpenStack, etc.
[...]

The Debian OpenStack packaging effort, when we were hosting it (the
maintainers eventually decided for the sake of consistency to move
it back into Debian's collaborative hosting instead) were in fact
done as forked copies of the Git repositories of official OpenStack
deliverables. Patch series and Git forks can be converted back and
forth, at some cost to developer efficiency, but ultimately are an
implementation detail.
-- 
Jeremy Stanley


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] [StarlingX] StarlingX code followup discussions

[Jeremy Stanley]

On 2018-05-22 17:41:18 -0400 (-0400), Brian Haley wrote:
[...]
> I read this the other way - the goal is to get all the forked code from
> StarlingX into upstream repos.  That seems backwards from how this should
> have been done (i.e. upstream first), and I don't see how a project would
> prioritize that over other work.
[...]

I have yet to see anyone suggest it should be prioritized over other
work. I expect the extracted and proposed changes/specs
corresponding to the divergence would be viewed on their own merits
just like any other change and ignored, reviewed, rejected, et
cetera as appropriate.
-- 
Jeremy Stanley


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] [StarlingX] StarlingX code followup discussions

[Julia Kreger]

On Tue, May 22, 2018 at 5:41 PM, Brian Haley  wrote:
> On 05/22/2018 04:57 PM, Jay Pipes wrote:
[trim]

> I read this the other way - the goal is to get all the forked code from
> StarlingX into upstream repos.  That seems backwards from how this should
> have been done (i.e. upstream first), and I don't see how a project would
> prioritize that over other work.

There is definitely value to be gained for both projects in terms of a
different point of view that might not have been able to play out in
the public community, but since we're dealing with squashed commits of
changes, it is really hard for us to delineate history/origin of code
fragments, and without that it makes it near impossible for projects
to even help them reconcile their technical debt because of that and
the lacking context surrounding that. It would be so much more
friendly to the community if we had stacks of patch files that we
could work with git.

>> I'm truly wondering why was this even open-sourced to begin with? I'm as
>> big a supporter of open source as anyone, but I'm really struggling to
>> comprehend the business, technical, or marketing decisions behind this
>> action. Please help me understand. What am I missing?
>
>
> I'm just as confused.

Can I add myself to the list of confused people wanting to understand
better? I can see and understand value, but context and understanding
as to why as I mentioned above is going to be the main limiter for
interaction.

__
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] [StarlingX] StarlingX code followup discussions

[Jay Pipes]

On 05/23/2018 12:49 PM, Colleen Murphy wrote:

On Tue, May 22, 2018, at 10:57 PM, Jay Pipes wrote:


Are any of the distributions of OpenStack listed at
https://www.openstack.org/marketplace/distros/ hosted on openstack.org
infrastructure? No. And I think that is completely appropriate.


Hang on, that's not quite true. From that list I see Mirantis, Debian, Ubuntu, 
and RedHat, who all have (or had until recently) significant parts of their 
distros hosted on openstack.org infrastructure and are/were even official 
OpenStack projects governed by the TC.


I believe you may be confusing packages (or package specs) with 
distributions?


Mirantis OpenStack was never hosted on an openstack infrastructure. Fuel 
is, as are deb spec files and Puppet manifests, etc. But the 
distribution of OpenStack is the collection of all those specs/build 
files along with a default configuration and things like project deltas 
exposed as patch files. Same goes for RDO, Canonical OpenStack, etc.



It's also important to make the distinction between hosting something on 
openstack.org infrastructure and recognizing it in an official capacity. 
StarlingX is seeking both, but in my opinion the code hosting is not the 
problem here.


Yep, you're absolutely right that there is a distinction between hosting 
and consuming the foundation's resources and recognizing StarlingX in 
some official capacity. I'm concerned about both items.


My concern with the former item is that I believe this is setting a 
precedent that the foundation's resources are being used to host a 
particular OpenStack distribution -- which is something I don't believe 
should happen. Vendor products/distributions [1] should be supported by 
that vendor, IMHO. [2]


My concern with the latter item is more an annoyance with what I see as 
Intel / Wind River playing the Linux Foundation against the OpenStack 
foundation to see which will bear the burden of supporting code that I 
feel is being dumped on the upstream community. I fully understand that 
Dean has been put into a very awkward situation with all of this, and I 
want to be clear that I mean no disrespect towards any Intel or Wind 
River engineer/contributor. My gripe is with the business/management 
decisions that led to this. Dean was very gracious in answering a number 
of my questions on the etherpad linked in the original post. Thank you 
to Dean for being gracious under fire.


Finally, I'd like to say that I did read the long discussion thread the 
TC had about this [3]. A number of the TC folks brought up interesting 
points about the subject at hand, and I recognize there's a bit of a 
damned-if-we-do-damned-if-we-don't situation. Jeremy pointed out concern 
about the optics of having the Linux Foundation hosting a fork of 
OpenStack and how bad that would look. A number of folks, including 
Jeremy, also brought up the potential renaming of the OpenStack 
Foundation to the Open Infrastructure Foundation and what such a rename 
might do to ease concerns over things like Airship and StarlingX. I 
don't personally feel a rename would ease much of the discontent, but 
I'm also clearly biased and recognize that I am so.


One point that I brought up on the etherpad was whether folks have 
considered an "edge constellation" instead of a fork of OpenStack? In 
other words, the edge constellation would be a description of an 
opinionated build of OpenStack (and other supporting services) that 
would be focused on the mobile/edge cloud use cases, but there would not 
be a fork of OpenStack. Anyway, I think it's worth considering at least; 
it's a sticky and awkward situation, for sure.


Best,
-jay

[1] Yes, even if that vendor has now chosen a different strategy of open 
sourcing their code versus keeping it proprietary


[2] For the record, I believe it was a mistake to put Mirantis' Fuel 
product (and let's face it, Fuel was a product of Mirantis) under the 
openstack.org's hosting.


[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-20.log.html


__
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] [StarlingX] StarlingX code followup discussions

[Jeremy Stanley]

On 2018-05-23 18:49:16 +0200 (+0200), Colleen Murphy wrote:
[...]
> It's also important to make the distinction between hosting
> something on openstack.org infrastructure and recognizing it in an
> official capacity. StarlingX is seeking both, but in my opinion
> the code hosting is not the problem here.

This may also be a poor time to mention that there have been
discussions within the Infra team for over a year about renaming the
infrastructure we're managing, since it's done in service of more
than just the OpenStack project. The hardest part has been coming up
with a good name. ;)
-- 
Jeremy Stanley


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] [StarlingX] StarlingX code followup discussions

[Matt Riedemann]

On 5/23/2018 9:49 AM, Colleen Murphy wrote:

Hang on, that's not quite true. From that list I see Mirantis, Debian, Ubuntu, 
and RedHat, who all have (or had until recently) significant parts of their 
distros hosted on openstack.org infrastructure and are/were even official 
OpenStack projects governed by the TC.


But isn't that primarily deployment tooling (Fuel, Charms, TripleO) 
rather than forks of other existing service projects like 
nova/cinder/ironic?


--

Thanks,

Matt

__
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] [StarlingX] StarlingX code followup discussions

[Colleen Murphy]

On Tue, May 22, 2018, at 10:57 PM, Jay Pipes wrote:
> 
> Are any of the distributions of OpenStack listed at 
> https://www.openstack.org/marketplace/distros/ hosted on openstack.org 
> infrastructure? No. And I think that is completely appropriate.

Hang on, that's not quite true. From that list I see Mirantis, Debian, Ubuntu, 
and RedHat, who all have (or had until recently) significant parts of their 
distros hosted on openstack.org infrastructure and are/were even official 
OpenStack projects governed by the TC.

It's also important to make the distinction between hosting something on 
openstack.org infrastructure and recognizing it in an official capacity. 
StarlingX is seeking both, but in my opinion the code hosting is not the 
problem here.

Colleen

__
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] [StarlingX] StarlingX code followup discussions

[Joshua Harlow]

Also I am concerned that the repo just seems to have mega-commits like:

https://github.com/starlingx-staging/stx-glance/commit/1ec64167057e3368f27a1a81aca294b771e79c5e

https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a 
(not so mega)


https://github.com/starlingx-staging/stx-glance/commit/1ec64167057e3368f27a1a81aca294b771e79c5e

I am very confused now as well; it feels a lot like a code dump (which I 
get and it's nice to see companies patches, but it seems odd that this 
would ever be put anywhere official and expect?/hope? people to dissect 
and extract code that starlingx obviously couldn't put the manpower 
behind to do the same).


Brian Haley wrote:

On 05/22/2018 04:57 PM, Jay Pipes wrote:

Warning: strong opinions ahead.

On 05/22/2018 02:54 PM, Dean Troyer wrote:

Developers will need to re-create a repo locally in
order to work or test the code and create reviews (there are more git
challenges here). It would be challenging to do functional testing on
the rest of STX in CI without access to all of the code.


Please don't take this the wrong way, Dean, but you aren't seriously
suggesting that anyone outside of Windriver/Intel would ever
contribute to these repos are you?

What motivation would anyone outside of Windriver/Intel -- who must
make money on this effort otherwise I have no idea why they are doing
it -- have to commit any code at all to StarlingX?


I read this the other way - the goal is to get all the forked code from
StarlingX into upstream repos. That seems backwards from how this should
have been done (i.e. upstream first), and I don't see how a project
would prioritize that over other work.


I'm truly wondering why was this even open-sourced to begin with? I'm
as big a supporter of open source as anyone, but I'm really struggling
to comprehend the business, technical, or marketing decisions behind
this action. Please help me understand. What am I missing?


I'm just as confused.

-Brian



My personal opinion is that I don't think that any products,
derivatives or distributions should be hosted on openstack.org
infrastructure.

Are any of the distributions of OpenStack listed at
https://www.openstack.org/marketplace/distros/ hosted on openstack.org
infrastructure? No. And I think that is completely appropriate.

Best,
-jay

__

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



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


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

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

[Brian Haley]

On 05/22/2018 04:57 PM, Jay Pipes wrote:

Warning: strong opinions ahead.

On 05/22/2018 02:54 PM, Dean Troyer wrote:

Developers will need to re-create a repo locally in
order to work or test the code and create reviews (there are more git
challenges here). It would be challenging to do functional testing on
the rest of STX in CI without access to all of the code.


Please don't take this the wrong way, Dean, but you aren't seriously 
suggesting that anyone outside of Windriver/Intel would ever contribute 
to these repos are you?


What motivation would anyone outside of Windriver/Intel -- who must make 
money on this effort otherwise I have no idea why they are doing it -- 
have to commit any code at all to StarlingX?


I read this the other way - the goal is to get all the forked code from 
StarlingX into upstream repos.  That seems backwards from how this 
should have been done (i.e. upstream first), and I don't see how a 
project would prioritize that over other work.


I'm truly wondering why was this even open-sourced to begin with? I'm as 
big a supporter of open source as anyone, but I'm really struggling to 
comprehend the business, technical, or marketing decisions behind this 
action. Please help me understand. What am I missing?


I'm just as confused.

-Brian


My personal opinion is that I don't think that any products, derivatives 
or distributions should be hosted on openstack.org infrastructure.


Are any of the distributions of OpenStack listed at 
https://www.openstack.org/marketplace/distros/ hosted on openstack.org 
infrastructure? No. And I think that is completely appropriate.


Best,
-jay

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



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

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

[Jay Pipes]

Warning: strong opinions ahead.

On 05/22/2018 02:54 PM, Dean Troyer wrote:

Developers will need to re-create a repo locally in
order to work or test the code and create reviews (there are more git
challenges here). It would be challenging to do functional testing on
the rest of STX in CI without access to all of the code.


Please don't take this the wrong way, Dean, but you aren't seriously 
suggesting that anyone outside of Windriver/Intel would ever contribute 
to these repos are you?


What motivation would anyone outside of Windriver/Intel -- who must make 
money on this effort otherwise I have no idea why they are doing it -- 
have to commit any code at all to StarlingX?


I'm truly wondering why was this even open-sourced to begin with? I'm as 
big a supporter of open source as anyone, but I'm really struggling to 
comprehend the business, technical, or marketing decisions behind this 
action. Please help me understand. What am I missing?


My personal opinion is that I don't think that any products, derivatives 
or distributions should be hosted on openstack.org infrastructure.


Are any of the distributions of OpenStack listed at 
https://www.openstack.org/marketplace/distros/ hosted on openstack.org 
infrastructure? No. And I think that is completely appropriate.


Best,
-jay

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

[openstack-dev] [StarlingX] StarlingX code followup discussions

[Dean Troyer]

StarlingX (aka STX) was announced this week at the summit, there is a
PR to create project repos in Gerrit at [0]. STX is basically Wind
River's Titanium Cloud product, which is a turn-key cloud deployment.
For background I have started putting notes, some faq-ish questions
and references to blog-ish materials in [1].

The alternatives I have thought of or have been suggested so far all
seem to be worse in some way.  The major objections I have heard are
around the precedent and messaging of the existence of OpenStack
project forks, independent of the form they take[2].  There is a
secondary concern about OpenStack Foundation hosting fork of other
outside projects.

At this point I am planning to change the review[0] to only add the
repos for the new sub-projects so we can continue getting things set
up while the discussions continue on how best to handle the upstream
work.  I want to continue those discussions wherever they will be
productive, respond here or find me at the summit.  IRC discussion has
been in #openstack-tc so far.

More background

The set of STX repos include a number of patches to upstream projects,
most of which are intended to be proposed upstream.  The patches
include features specific to Titanium's use cases and bug fixes as
well as some bits that may or may not be useful in other use cases.
The intention is to reduce this technical debt to zero; there were a
handful of repos where the patch count was reduced to zero that we
were able to eliminate in the transition to StarlingX.  This is the
goal for all of the remaining upstream repos.

I chose to maintain the status of the Titanium upstream work as git
repos for developer and testing convenience, as opposed to publishing
patch file sets. Developers will need to re-create a repo locally in
order to work or test the code and create reviews (there are more git
challenges here). It would be challenging to do functional testing on
the rest of STX in CI without access to all of the code.

dt


[0] https://review.openstack.org/#/c/569562/
[1] https://etherpad.openstack.org/p/stx-faq
[2] Honestly I don't think that hosting a repo of patches to OpenStack
projects is any different than hosting the repo itself.  Also, anyone
remember Qmail? :)

-- 

Dean Troyer
dtro...@gmail.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