Re: [openstack-dev] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

Thanks for the pointer Clark. We will look into using that, although we were 
running out of time on the Mitaka release to get something like that 
implemented.

Craig Bryant is in the process of manually updating the versions in the pom 
files to match the Mitaka tags. A couple of reviews are available at

monasca-common: https://review.openstack.org/#/c/301925/
monasca-api: https://review.openstack.org/#/c/301925


Assuming that is an acceptable method, we can also update 

monasca-thresh
monasca-persister

using the same approach. 

Note, I thought he was going to try and pull the tag from git, but maybe that 
didn't turn out OK.

Assuming those work, then at least we would have jars available that match the 
tags for the Mitaka release.








On 4/5/16, 1:10 PM, "Clark Boylan"  wrote:

>On Tue, Apr 5, 2016, at 11:56 AM, Hochmuth, Roland M wrote:
>> Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that
>> I've caused.
>> 
>> It sounds like all Python projects/deliverables are in reasonable shape,
>> but if not, please let me know. 
>> 
>> Not sure what we should do about the jars at this point. We had started
>> to discuss a plan to manually copy the jars over to the proper location.
>> I was hoping we could just do this temporarily for Mitaka. Unfortunately,
>> there are a few steps that need to be resolved prior to doing that.
>> 
>> Currently, the java builds overwrite the previous build. The version
>> number of the jar that is built, matches the version in the pom file.
>> See, http://tarballs.openstack.org/ci/monasca-thresh/, for an example.
>> 
>> What we are looking into is modifying the pom files for the java repos,
>> so that the version number of the jar matches the tag when built (not
>> what is in the pom), and modifying the name of the jar, by removing the
>> word SNAPSHOT.
>> 
>> If we do that, we think we can get a name for the jar with a version that
>> matches the latest tag on whatever branch is being used. This should be
>> similar to how the Python wheels that are named.
>> 
>> We could manually copy in the short-term. But the goal is to add an
>> automatic copy to the appropriate location in,
>> http://tarballs.openstack.org/.
>> 
>> Unfortunately, for the java related deliverables, it sounds like we are a
>> little late for all this to get done prior to Mitaka. Not sure if this
>> can be added post Mitaka.
>
>The infra team has to publish jars as well and has a set of jobs for
>that at [0]. It should figure out your versions from git as well and set
>them all automagically with the correct maven configuration. You might
>be able to just add these jobs assuming you use maven.
>
>[0]
>https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/maven-plugin-jobs.yaml
>
>Clark
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][release] missing build artifacts

[Clark Boylan]

On Tue, Apr 5, 2016, at 11:56 AM, Hochmuth, Roland M wrote:
> Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that
> I've caused.
> 
> It sounds like all Python projects/deliverables are in reasonable shape,
> but if not, please let me know. 
> 
> Not sure what we should do about the jars at this point. We had started
> to discuss a plan to manually copy the jars over to the proper location.
> I was hoping we could just do this temporarily for Mitaka. Unfortunately,
> there are a few steps that need to be resolved prior to doing that.
> 
> Currently, the java builds overwrite the previous build. The version
> number of the jar that is built, matches the version in the pom file.
> See, http://tarballs.openstack.org/ci/monasca-thresh/, for an example.
> 
> What we are looking into is modifying the pom files for the java repos,
> so that the version number of the jar matches the tag when built (not
> what is in the pom), and modifying the name of the jar, by removing the
> word SNAPSHOT.
> 
> If we do that, we think we can get a name for the jar with a version that
> matches the latest tag on whatever branch is being used. This should be
> similar to how the Python wheels that are named.
> 
> We could manually copy in the short-term. But the goal is to add an
> automatic copy to the appropriate location in,
> http://tarballs.openstack.org/.
> 
> Unfortunately, for the java related deliverables, it sounds like we are a
> little late for all this to get done prior to Mitaka. Not sure if this
> can be added post Mitaka.

The infra team has to publish jars as well and has a set of jobs for
that at [0]. It should figure out your versions from git as well and set
them all automagically with the correct maven configuration. You might
be able to just add these jobs assuming you use maven.

[0]
https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/maven-plugin-jobs.yaml

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that I've 
caused.

It sounds like all Python projects/deliverables are in reasonable shape, but if 
not, please let me know. 

Not sure what we should do about the jars at this point. We had started to 
discuss a plan to manually copy the jars over to the proper location. I was 
hoping we could just do this temporarily for Mitaka. Unfortunately, there are a 
few steps that need to be resolved prior to doing that.

Currently, the java builds overwrite the previous build. The version number of 
the jar that is built, matches the version in the pom file. See, 
http://tarballs.openstack.org/ci/monasca-thresh/, for an example.

What we are looking into is modifying the pom files for the java repos, so that 
the version number of the jar matches the tag when built (not what is in the 
pom), and modifying the name of the jar, by removing the word SNAPSHOT.

If we do that, we think we can get a name for the jar with a version that 
matches the latest tag on whatever branch is being used. This should be similar 
to how the Python wheels that are named.

We could manually copy in the short-term. But the goal is to add an automatic 
copy to the appropriate location in, http://tarballs.openstack.org/.

Unfortunately, for the java related deliverables, it sounds like we are a 
little late for all this to get done prior to Mitaka. Not sure if this can be 
added post Mitaka.

Regards --Roland



On 4/5/16, 3:15 AM, "Thierry Carrez"  wrote:

>Davanum Srinivas wrote:
>> Please see below:
>>
>> On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann  wrote:
>>> Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
 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/
>
>Thanks dims!
>
>Roland: Now we'll need a 0.0.3 tag request on stable/mitaka to trigger a 
>tarball rebuild.
>
>If done quickly, that should let us keep Monasca deliverables in Mitaka.
>
>-- 
>Thierry Carrez (ttx)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][release] missing build artifacts

[Thierry Carrez]

Davanum Srinivas wrote:

Please see below:

On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann  wrote:

Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:

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/


Thanks dims!

Roland: Now we'll need a 0.0.3 tag request on stable/mitaka to trigger a 
tarball rebuild.


If done quickly, that should let us keep Monasca deliverables in Mitaka.

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][release] missing build artifacts

[Davanum Srinivas]

Please see below:

On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann  wrote:
> Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
>> 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"  wrote:
>>
>> >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
>> >> 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 

Re: [openstack-dev] [monasca][release] missing build artifacts

[Doug Hellmann]

Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
> 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).

> 
> 
> 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"  wrote:
> 
> >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
> >> 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
> 

Re: [openstack-dev] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

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.


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.
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.

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"  wrote:

>Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
>> 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"  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 

Re: [openstack-dev] [monasca][release] missing build artifacts

[Doug Hellmann]

Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
> 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"  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

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.

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.

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.

Let me know how you want to proceed.

Regards --Roland



On 4/1/16, 1:21 PM, "Doug Hellmann"  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev