Open Stack

On 04/06/2017 03:51 PM, Jimmy McArthur wrote:
> Cool. Thanks Monty!
>
>> Monty Taylor <mailto:mordred at inaugust.com>
>> April 6, 2017 at 3:21 PM
>> On 04/06/2017 11:58 AM, Jimmy McArthur wrote:
>>> Assuming this format is accepted, do you all have any sense of when this
>>> data will be complete for all projects?
>>
>> Hopefully "soon" :)
>>
>> Honestly, it's not terribly difficult data to produce, so once we're
>> happy with it and where it goes, crowdsourcing filling it all in
>> should go quickly.
>>
>>>> Jimmy McArthur <mailto:jimmy at openstack.org>
>>>> April 5, 2017 at 8:59 AM
>>>> FWIW, from my perspective on the Project Navigator side, this format
>>>> works great. We can actually derive the age of the project from this
>>>> information as well by identifying the first release that has API data
>>>> for a particular project. I'm indifferent about where it lives, so I'd
>>>> defer to you all to determine the best spot.
>>>>
>>>> I really appreciate you all putting this together!
>>>>
>>>> Jimmy
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> Thierry Carrez <mailto:thierry at openstack.org>
>>>> April 5, 2017 at 5:28 AM
>>>>
>>>> Somehow missed this thread, so will repost here comments I made
>>>> elsewhere:
>>>>
>>>> This looks good, but I would rather not overload the releases
>>>> repository. My personal preference (which was also expressed by
>>>> Doug in the TC meeting) would be to set this information up in a
>>>> "project-navigator" git repo that we would reuse for any information we
>>>> need to collect from projects for accurate display on the project
>>>> navigator. If the data is not maintained anywhere else (or easily
>>>> derivable from existing data), we would use that repository to collect
>>>> it from projects.
>>>>
>>>> That way there is a clear place to go to to propose fixes to the
>>>> project
>>>> navigator data. Not knowing how to fix that data is a common complaint,
>>>> so if we can point people to a git repo (and redirect people from there
>>>> to the places where other bits of information happen to live) that
>>>> would
>>>> be great.
>>>>
>>>> Monty Taylor <mailto:mordred at inaugust.com>
>>>> April 4, 2017 at 5:47 PM
>>>> Hey all,
>>>>
>>>> As per our discussion in today's TC meeting, I have made a document
>>>> format for reporting versions to the project navigator. I stuck it in
>>>> the releases repo:
>>>>
>>>>   https://review.openstack.org/453361
>>>>
>>>> Because there was already per-release information there, and the
>>>> governance repo did not have that structure.
>>>>
>>>> I've included pseudo-code and a human explanation of how to get from a
>>>> service's version discovery document to the data in this document, but
>>>> also how it can be maintained- which is likely to be easier by hand
>>>> than by automation - but who knows, maybe we decide we want to make a
>>>> devstack job for each service that runs on tag events that submits a
>>>> patch to the releases repo. That sounds like WAY more work than once a
>>>> cycle someone adding a few lines of json to a repo - but *shrug*.
>>>>
>>>> Basing it on the version discovery docs show a few things:
>>>>
>>>> * "As a user, I want to consume an OpenStack Service's Discovery
>>>> Document" is a thing people might want to do and want to do
>>>> consistently across services.
>>>>
>>>> * We're not that far off from being able to do that today.
>>>>
>>>> * Still, like we are in many places, we're randomly different in a few
>>>> minor ways that do not actually matter but make life harder for our
>>>> users.
>>>>
>>>> Thoughts and feedback more than welcome!
>>>> Monty
>>>>
>>>> __________________________________________________________________________
>>>>
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Jimmy McArthur <mailto:jimmy at openstack.org>
>> April 6, 2017 at 11:58 AM
>> Assuming this format is accepted, do you all have any sense of when
>> this data will be complete for all projects?
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Jimmy McArthur <mailto:jimmy at openstack.org>
>> April 5, 2017 at 8:59 AM
>> FWIW, from my perspective on the Project Navigator side, this format
>> works great. We can actually derive the age of the project from this
>> information as well by identifying the first release that has API data
>> for a particular project. I'm indifferent about where it lives, so I'd
>> defer to you all to determine the best spot.
>>
>> I really appreciate you all putting this together!
>>
>> Jimmy
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Thierry Carrez <mailto:thierry at openstack.org>
>> April 5, 2017 at 5:28 AM
>>
>> Somehow missed this thread, so will repost here comments I made elsewhere:
>>
>> This looks good, but I would rather not overload the releases
>> repository. My personal preference (which was also expressed by
>> Doug in the TC meeting) would be to set this information up in a
>> "project-navigator" git repo that we would reuse for any information we
>> need to collect from projects for accurate display on the project
>> navigator. If the data is not maintained anywhere else (or easily
>> derivable from existing data), we would use that repository to collect
>> it from projects.
>>
>> That way there is a clear place to go to to propose fixes to the project
>> navigator data. Not knowing how to fix that data is a common complaint,
>> so if we can point people to a git repo (and redirect people from there
>> to the places where other bits of information happen to live) that would
>> be great.
>>
>> Monty Taylor <mailto:mordred at inaugust.com>
>> April 4, 2017 at 5:47 PM
>> Hey all,
>>
>> As per our discussion in today's TC meeting, I have made a document
>> format for reporting versions to the project navigator. I stuck it in
>> the releases repo:
>>
>>   https://review.openstack.org/453361
>>
>> Because there was already per-release information there, and the
>> governance repo did not have that structure.
>>
>> I've included pseudo-code and a human explanation of how to get from a
>> service's version discovery document to the data in this document, but
>> also how it can be maintained- which is likely to be easier by hand
>> than by automation - but who knows, maybe we decide we want to make a
>> devstack job for each service that runs on tag events that submits a
>> patch to the releases repo. That sounds like WAY more work than once a
>> cycle someone adding a few lines of json to a repo - but *shrug*.
>>
>> Basing it on the version discovery docs show a few things:
>>
>> * "As a user, I want to consume an OpenStack Service's Discovery
>> Document" is a thing people might want to do and want to do
>> consistently across services.
>>
>> * We're not that far off from being able to do that today.
>>
>> * Still, like we are in many places, we're randomly different in a few
>> minor ways that do not actually matter but make life harder for our
>> users.

There is a new repo now:

http://git.openstack.org/cgit/openstack/project-navigator-data

I have pushed up two different patches with two different approaches:

https://review.openstack.org/#/c/454691
https://review.openstack.org/#/c/454688

One is a single file per release. The other is a file per service per 
release.

Benefits of the single-file are that it's a single file to pull and parse.

Benefits of the multi-file approach are that projects can submit 
documents for themselves as patches without fear of merge conflicts, and 
that the format is actually _identical_ to the format for version 
discovery from the API-WG, minus the links section.

I think I prefer the multi-file approach, but would be happy either way.