Just to followup since the required packages are finally available, the
patches have been updated and are passing CI now.
https://review.openstack.org/#/c/202763/
-Alex
On Fri, Jul 24, 2015 at 8:32 AM, Alex Schultz wrote:
> Unfortunately we got stuck with package availability issues. It was
>
Unfortunately we got stuck with package availability issues. It was
successful without using librarian packages for building, but since we need
to leverage packages the work to get packaged versions of the code has
unfortunately blocked this. I've got the packages built, but the time to
get them to
Do we have any success here.. ?
On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz wrote:
> Vladimir,
>
> Thanks. Can you point me to the error for perestroika? I'd be happy to
> take a look as well. I spent most of Friday throwing various options at the
> CI system to try and figure out how to get t
Vladimir,
Thanks. Can you point me to the error for perestroika? I'd be happy to
take a look as well. I spent most of Friday throwing various options at the
CI system to try and figure out how to get the spec to work with the CI
fuel-library package building so perhaps there's a different way to
Alex,
As I've just found out this package available here [1] is not actually
build with your patch (instead it is from previous successful build). Looks
like "perestroika" can not build this package due to some environment
related issues. I've poked Dmitry Burmistrov to check it out.
However, your
Alex,
Yes, spec is much better place to introduce this. BTW, "perestroika" builds
new package for every commit and patch set and publishes them via HTTP.
Please check here
http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noar
Not until we start using it then any ci that tests with that module will
validate the modules inclusion. You can check the output of the jobs as we
are printing what modules are managed by librarian.
-Alex
On Jul 17, 2015 6:17 PM, "Andrew Woodward" wrote:
> Fantastic, do we have some way to vali
Fantastic, do we have some way to validate that the module was pulled in
properly as part of fuel-library CI?
On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz wrote:
> Hey All,
>
> I've figured it out without having to modify the fuel-main build code.
> I've updated the fuel-library spec with a buil
Hey All,
I've figured it out without having to modify the fuel-main build code. I've
updated the fuel-library spec with a build action that invokes the script
to pull down external modules. Please take some time to review the two
reviews out there for this change to see if there are any issues wi
On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Alex,
>
> Great that you did this. Now I think I can prepare fuel-main patch to
> invoke this script right before building fuel-library package. I'll add you
> to review it. Is it ok if I do this monday morni
Hey Vladimir,
So I've been playing with it at the moment because I think the better place
to do the script execution is as part of the build process controlled by
the fuel-library7.0 spec file[0]. It seems to be a valid way to do it (and
would work for our CI jobs to) but the issue i'm running in
Alex,
Great that you did this. Now I think I can prepare fuel-main patch to
invoke this script right before building fuel-library package. I'll add you
to review it. Is it ok if I do this monday morning?
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz wrote:
> Hey Vladimir,
>
Hey Vladimir,
On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Alex,
>
> Gathering upstream modules certainly should be implemented as a separate
> script so as to make it possible to use it wherever we need this (tests,
> builds, etc.) According to builds
Alex,
Gathering upstream modules certainly should be implemented as a separate
script so as to make it possible to use it wherever we need this (tests,
builds, etc.) According to builds there are two things
1) We have so called "perestroika" package build system (Dmitry Burmistrov
is a main contr
I believe build_repo function is the best way to do this [0]. So for
fuel-library we'll need to run a shell script right from the repo before
'touch $$@'. We can make it either conditional ( test -f
./path/additional_build_script.sh && bash ./path/additional_build_script.sh
) or as additional param
Hey Alex,
On Jul 17, 2015 4:32 AM, "Aleksandr Didenko" wrote:
>
> Hi,
>
> I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build pr
Hi,
I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build process and CI jobs.
Regards,
Alex
On Thu, Jul 16, 2015 at 11:17 PM, Al
Hello everyone,
I have committed the initial configuration required to start leveraging
librarian-puppet as part of the way we pull in upstream puppet modules[0].
Additionally, I have also committed a change that would pull in the
openstack-ironic module[1]. The one piece that is missing from thi
18 matches
Mail list logo