Open Stack

Assuming this format is accepted, do you all have any sense of when this 
data will be complete for all projects?

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170406/3d0c2d83/attachment.html>