Please see below: On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann <[email protected]> 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" <[email protected]> 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" <[email protected]> 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: >> >> >[email protected]?subject:unsubscribe >> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >__________________________________________________________________________ >> >OpenStack Development Mailing List (not for usage questions) >> >Unsubscribe: [email protected]?subject:unsubscribe >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
