[Openstack-docs] Links to another manual

Denis Bradford denisbatgm at gmail.com
Thu Jul 18 22:19:29 UTC 2013


fwiw, here's the link that fails, in computescheduler.xml:

  If per-aggregate value is not found, it falls back to the <link
linkend="compute-scheduler-config-ref">default setting</link>.

The link target is in ch_computescheduler.xml, a chapter in the
openstack-config manual

And I thought I was doing something trivial for my first checkin :-P

On Thu, Jul 18, 2013 at 4:22 PM, David Cramer
<david.cramer at rackspace.com> wrote:
> On 07/18/2013 03:08 PM, Lorin Hochstein wrote:
>> David:
>>
>> Yes, the validation script are only looking at individual files right
>> now, which is why they don't catch missing cross-references.
>>
>> I agree that maven would be better for gating. But maven isn't currently
>> gating, is it?
>
> Now that I think of it more, Maven is the only thing that can really
> validate this because you might have a file that's valid on the file
> system but invalid after profiling:
>
> Say you have <section xml:id="foo" condition="rhel">...</section> and
> elsewhere <xref linkend="foo"/>. When you build validate with your
> script, all is well because the IDREF linkend="foo" matches
> xml:id="foo", but if you build with profileCondition=ubuntu, that
> section is removed and you have a broken link.
>
> The build will blow up if there's an IDREF without a matching ID in the
> document UNLESS failOnValidationError=no.
>
> As of 1.6.x, Maven validates the doc twice: first after resolving
> xincludes it validates without checking IDREFs, then again towards the
> end after all profiling etc, it checks IDREFs as well. This is to catch
> the situation where the doc was valid but was made invalid by filtering
> out content. In 1.8.0, I give you a more helpful error message that
> suggests opening an intermediate file in the target dir and validating
> it so you can see the actual error (line numbers are meaningless since
> the original source file has been manipulated by resolving xincludes etc).
>
> Does that make sense?
>
> If leaving the failOnValidationError=no door available is a bad thing, I
> could easily make it so failOnValidationError is ignored if
> branding=openstack. Or perhaps Jenkins could pass in
> failOnValidationError=yes, which would override what's in the pom (or
> some other trick to make sure Jenkins never builds something where
> validation doesn't kill the build).
>
> David
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



More information about the Openstack-docs mailing list