Re: GET /v1/server/version

[Sam Corbett <sa...@cloudsoftcorp.com>]

Hi,

I've opened a pull request for this idea:
https://github.com/apache/incubator-brooklyn/pull/675

Feedback welcome.

Thanks,

Sam


On 7 May 2015 at 15:14, Alex Heneveld <al...@cloudsoftcorp.com>
wrote:

>
> Sounds great.  I support  collecting Brooklyn-Feature-* headers.
>
> For OSGi symbolic-name is essential.
>
> BTW - sourceUrl might be a useful one to add.
>
> Best
> Alex
>
>
>
> On 07/05/2015 13:52, Sam Corbett wrote:
>
>> I imagined that the output would be a list like:
>>
>> "features": [
>>     {
>>         "name": "Entities for Foo",
>>         "version": "3.0.1",
>>         "buildDate": "<date in ISO 8601 format>",
>>         "buildBranch": "master",
>>         "buildId": "<sha1/other identifier>",
>>     },
>>     {
>>         "name": "Clocker",
>>         "version": "0.8.1",
>>         ...
>>     }
>> ]
>>
>> I prefer a list to a map in case a server ends up in a state where two
>> bundles report the same name/version.
>>
>> I'm unsure about the keys starting build (buildId replaces the Sha1
>> attribute in my first email). Should downstream projects automatically give
>> this information away? The main Brooklyn build uses the
>> buildnumber-maven-plugin to get a SHA1, but the plugin's documentation is
>> vague about what other SCMs it supports. I think Git, SVN, Mercurial and
>> CVS.
>>
>> Alternatively we could scan for and include all attributes prefixed
>> "Brooklyn-Feature" rather than a known set of attributes. This would be
>> less efficient but more flexible.
>>
>> Sam
>>
>> On 06/05/2015 23:45, Alex Heneveld wrote:
>>
>>>
>>> Sam-
>>>
>>> Big +1.  This would be very useful to identify the versions of things
>>> supplying catalog items and other snippets.
>>>
>>> How would we communicate which feature the other metadata belongs to?
>>> Extracting name / symbolic name / jar filename / all the above as keys in
>>> the map for each feature -- plus version in the case of OSGi bundles?
>>>
>>> Should features itself be a list, or could it be a map keyed off
>>> symbolic-name:version or jar-filename-url ?
>>>
>>> Aled-  I think a "feature" would just be any jar or bundle which
>>> included this metadata.  Our archetype should include this so all
>>> user-supplied bundles have this info, plus downstream projects could also
>>> use it.
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 06/05/2015 23:17, Aled Sage wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> Nice suggestions.
>>>>
>>>> Definitely agree with adding "buildDate".
>>>>
>>>> For "features", I wonder if that justifies its own URL. For example GET
>>>> /v1/server/features.
>>>>
>>>> What kind of features are you thinking of, which would be included via
>>>> the manifest.mf approach?
>>>>
>>>> Aled
>>>>
>>>>
>>>> On 06/05/2015 20:05, Sam Corbett wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> At the moment if you GET /v1/server/version the response is something
>>>>> like:
>>>>>
>>>>> {
>>>>>      "buildBranch": "versions",
>>>>>      "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
>>>>>      "version": "0.7.0-SNAPSHOT"
>>>>> }
>>>>>
>>>>> I'd like to extend this to include two new keys: "buildDate" and
>>>>> "features".
>>>>>
>>>>> Hopefully the first of these is self-explanatory!
>>>>>
>>>>> The second would be the result of an inspection of Brooklyn's
>>>>> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
>>>>> bundles) for all MANIFEST.MF resources that contain attributes named
>>>>> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1,
>>>>> Version and
>>>>> Date. The result would be a dynamic list of the server's Brooklyn-aware
>>>>> modules that I think corresponds to a profile of a server's
>>>>> capabilities.
>>>>>
>>>>> Any thoughts or adjustments?  With appropriate configuration in
>>>>> brooklyn-downstream-parent's pom the scheme could be applied to
>>>>> downstream
>>>>> projects automatically. If I did this work I would also remove the
>>>>> existing
>>>>> build-metadata.properties file that populates the information above.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Sam
>>>>>
>>>>>
>>>>
>>>
>>
>