Open Stack

All, we have modified our ingest tasks to look for this new data. Can we 
get an ETA on when to expect updates from the majority of projects? 
Right now, there isn't too much to test with.

Cheers,
Jimmy

> Thierry Carrez <mailto:thierry at openstack.org>
> April 14, 2017 at 3:21 AM
>
> OK approved.
>
> Doug Hellmann <mailto:doug at doughellmann.com>
> April 13, 2017 at 11:43 AM
>
> +1
>
> The multi-file format was what the navigator team wanted, and there's
> plenty of support for it among other reviewers. Let's move this forward.
>
> Doug
>
> __________________________________________________________________________
> 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 13, 2017 at 11:03 AM
>
> Do we really need the TC approval on this ? It's not a formal governance
> change or anything.
>
> Whoever has rights on that repo could approve it now and ask for
> forgiveness later :)
>
> Monty Taylor <mailto:mordred at inaugust.com>
> April 13, 2017 at 10:25 AM
> On 04/13/2017 08:28 AM, Jimmy McArthur wrote:
>> Just checking on the progress of this. :)
>
> Unfortunately a good portion of the TC was away this week at the 
> leadership training so getting a final ok on it was a bit stalled. 
> It's seeming like the multi-file version is the one most people like 
> though, so I'm mostly expecting that to be what we end up with. We 
> should be able to get final approval by Tuesday, and then can work on 
> getting all of the project info filled in.
>
>>> Monty Taylor <mailto:mordred at inaugust.com>
>>> April 7, 2017 at 7:05 AM
>>>
>>>
>>> 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.
>>>
>>> __________________________________________________________________________ 
>>>
>>>
>>> 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 3:51 PM
>>> Cool. Thanks 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
>>> 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
>>
>>
>>
>> __________________________________________________________________________ 
>>
>> 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 13, 2017 at 8:28 AM
> Just checking on the progress of this. :)
>
>
> __________________________________________________________________________
> 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/20170418/80d67a6c/attachment.html>