Open Stack

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.
>
> 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/db5d4bbc/attachment.html>