Open Stack

Please see below:

On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +0000:
>> Hi Doug, You had mentioned issues with three repos:
>>
>> 1. monasca-ceilometer
>> 2. monasca-log-api
>> 3. monasca-thresh
>>
>> All the repos that have Python code I believe are in reasonable shape with respect to the Python deliverables except for the following two repos:
>>
>> 1. monasca-ceilometer
>> 2. monasca-log-api
>>
>> I'm not sure we should attempt to resolve these two repos for the Mitaka release, but we can try. It might be too late. They aren't in heavy usage and are relatively new.
>
> I think for those you were missing the "venv" environment in tox.ini
> that the jobs use to run arbitrary commands. Have a look at some of the
> other repos for an example of how to set that up, or ask the infra team
> (I'm not sure where it's documented, unfortunately, or I would direct
> you there).

The monasca-log-api venv problem has been fixed in:
https://review.openstack.org/#/c/299936/


>>
>>
>> monasca-thresh is a pure Java component.
>>
>> In the process of looking at monasca-thresh it looks like there is a general issue with all the Java deliverables. All the Java jars are built and uploaded in their respective folders such as, http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we don't move the jars that are in this directory up a level to http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to get resolved.
>>
>>
>> A proposal that I think would resolve this is as follows:
>>
>> 1. Update versions of Java jars in the pom.xml for each project to something like 2.0 on the stable/mitaka branch. This will result in a new jar file being created with a nice version and name. Note, this step isn't necessary, but if we did this we would have a nice version for Mitaka.
>
> If the artifacts exist but are in the "wrong" place, maybe someone
> from the infra team can copy them into place for you. Then if you
> give us an example of what the filenames are, the release team can
> update the tools in the releases repo to generate links to them (I
> assume, for example, they are not .tar.gz files).
>
>> 2. Figure out how to copy the jars over to their respective folders in http://tarballs.openstak.org. For Python I think the script that does this is publish-to-pypi, but for Java code, not sure exactly what needs to be done.
>
> Yes, you need to work with infra to set up the necessary build scripts.
> It's probably not realistic to do this in the next week, but if you get
> the existing files copied into place then you can work on updating the
> job before the Newton-1 milestone tagging deadline.
>
> Doug
>
>>
>> I think the two steps above would get us in compliance again for monasca-thresh and all the Java code in the other repos.
>>
>> Does that seem like a reasonable plan at this point?
>>
>> Regards --Roland
>>
>> On 4/1/16, 2:36 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
>>
>> >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +0000:
>> >> Hi Doug, Sorry, this is our first release and we want to do the right thing.
>> >>
>> >> monasca-ceilometer is the code that plugs into the Ceilometer publisher and Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca API and use Monasca as a storage backend. We don't create a pypi for this component.
>> >
>> >How do you users receive that code and install it? We at least need
>> >a tarball built. If you don't want to publish to pypi, you can use
>> >the job definitions that the Python server projects use to build
>> >artifacts.
>> >
>> >> monasca-log-api is probably not set up completely, but it should be similar to the monasca-api.
>> >>
>> >> monasca-thresh remains purely Java code. There is a build, but it isn't a Python build so there isn't a tox.ini. Not sure how to deliver this, but the current java build overwrites the jar each time it builds so it sounds like that would need to be fixed.
>> >
>> >Are those JAR files going somewhere we could link to?
>> >
>> >>
>> >> I guess, judging by the issues, I don't quite understand what "deliverables" are. I was thinking it was the tagged code, but obviously it includes the build too. It sounds like we have more work ahead of us.
>> >
>> >Most of our distributors want a tarball or sdist or other artifact they
>> >can use to build a package from. For the Python-based apps, we have
>> >templates you can use in the zuul/layout.yaml file to introduce those
>> >jobs into the right zuul queues. The release or infra teams can help you
>> >identify the right template to use.
>> >
>> >> Let me know how you want to proceed.
>> >
>> >We only want to be linking to things we're actually publishing. The
>> >first patch I mentioned removes the links so the Monasca projects
>> >that don't have builds. The second patch removes the projects
>> >entirely, but if we can update the page to link to a downloadable
>> >artifact (rather than just a git repo tag) then we can keep the
>> >projects in the list. We can get downloadable artifacts by having
>> >you add build jobs and then having the release team tag again as a
>> >new release candidate, or if there are already artifacts somewhere
>> >(like the JAR file) we can set up the releases repo to link there.
>> >
>> >Doug
>> >
>> >>
>> >> Regards --Roland
>> >>
>> >> On 4/1/16, 1:21 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
>> >>
>> >> >Monasca team,
>> >> >
>> >> >We noticed in our audit of the links on
>> >> >http://releases.openstack.org/mitaka/index.html that the links to
>> >> >the build artifacts for monasca-ceilometer, monasca-log-api, and
>> >> >monasca-thresh point to missing files. These repositories either
>> >> >don't seem to have any real build jobs configured in
>> >> >openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
>> >> >set up correctly (or both), so it's not clear how tagging is producing
>> >> >a release for you.
>> >> >
>> >> >For now, we are disabling links to the artifacts for those repos
>> >> >via https://review.openstack.org/300457 but we're also planning to
>> >> >remove them from the official Mitaka page since there don't
>> >> >appear to be any actual related deliverables
>> >> >(https://review.openstack.org/300619).
>> >> >
>> >> >It would be good to understand what your intent is for builds. Can
>> >> >you follow up here on this thread with some details?
>> >> >
>> >> >Thanks,
>> >> >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
>> >
>> >__________________________________________________________________________
>> >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



-- 
Davanum Srinivas :: https://twitter.com/dims