Hello Martin,
so is there some repository that you use to track packaging changes when
you don't contribute back to Juniper/contrail-packages?
I didn't found such repository or any more informations on how syseleven
builds are done, so that was the main reason why we have chosen to use
Juniper/contrail-packages to build packages and contribute back to it.
Are your changes and restructuring so huge or incompatible so they can't
be contributed back to Juniper/contrail-packages?
Also which build is what you are using in real deployment? For example I
didn't found package contrail-nova-vif in any of Syseleven's builds
(including R2.20) and it's required for Nova API to start. So
syseleven's distribution doesn't seem to be complete enough to be used
as is.
BTW I am going to finish and contribute build of contrail-nova-vif to
Juniper/contrail-packages soon.
Anyway it would be great to unify these builds, with support from
Juniper where possible (eg. for third party stuff you have mentioned)
maybe replacing supervisord by upstart/systemd integration - but these
changes would require fixes in upstream code (nodemgr for sure, maybe
other components).
I would prefer keeping package builds in Juniper/contrail-packages at
the moment (if it's possible) or create Debian packaging team and use
Debian's Alioth.
The second option would be better if we are strong enough for it :-)
Filip
On 07/16/2015 07:49 AM, Martin Gerhard Loschwitz wrote:
Good morning,
Am 15.07.2015 um 22:17 schrieb Filip Pytloun <[email protected]>:
Hello Martin,
there are several reasons why we have decided to make our own build:
- at the beginning syseleven packages seemed to be built using
contrail-packages as is (but now it seems there are probably some differences?)
Our packages are still built using the pristine Contrail source as delivered by
GitHub.
Let's take contrail - 2.20~test+1+git+09345e6-1+syseleven2 from
https://launchpad.net/~syseleven-platform/+archive/ubuntu/contrail-2.20/+packages
as an example: The last part of the version number (everything behind the last
+) is
the Git commit ID that was used as source for these packages. There have been a
number of changes to the source:
* Strip out the third_party-stuff after having built proper debian packages of
all the
components that are introduced by third_party stuff -- this alone accomodates
for a
number of patches in debian/patches
* Numerous bug fixes backported from R2.10 and R2.20 to work around issues that
we found in our Contrail installation, mostly suggested by Juniper
All patches can be found in the debian/patches subdirectory, so it's
transparent by
all means to figure out how our contrail sources are different from the
official ones.
Speaking of which: The debian/ subdirectory is also based on what can be found
in
the packaging git repository; there were, however, a number of changes that were
required due to the package restructuring I conducted. Oh, and I did stuff like
adding
back upstart files for all the Contrail daemons because Upstart is what Ubuntu
14.04
uses as its default init system and if you want to support Ubuntu 14.04, you
need to
have upstart scripts for the stuff.
- still there are some missing packages so it doesn't seem to be deployable
easily
For R2.20, we haven't build all the packages yet. For R2.0, we're running a
cluster
automatically deployed with puppet-contrail using exactly these packages. We
are,
in fact, probably not covering the complete Contrail control feature set yet
(we have
left out all the nodemgr stuff, for instance). But the basic functionality is
given by all
means.
- we wanted to have possibility to patch our builds and have some more control
over it
See answer to 1. The Debian Package Source Format 3.0 supports a Quilt mode that
will easily allow to introduce patches and keep track of them.
- we decided not to use official distribution from contrail-packaging, because
unfortunately it doesn't meet expected quality standards on packaging
We're totally on the same side here.
- also making our builds gives us some deeper insight on how the machine works
under the hood
That I can relate to, too.
Anyway I would like to join and maintain contrail-packages so anyone can make
own build and deploy without reinventing the wheel.
Possibly we can try to contribute to Debian so Opencontrail may be part of
Debian and Ubuntu distributions once.
Filip
I'll be more than happy to help. As pointed out in my answer to Robert, there
are some
show stoppers for this though. The third_party stuff is a major problem that we
can
either wait for Juniper to solve or solve on our own. The SysEleven repos have
proper
builds of all packages that would be build by the third_party directory, so
there is a
base to start with. Our contrail-controller packages also contain the patches
required to
make contrail-controller compile without anything from third_party, using the
proper
packages instead. We'd just need a group of people large enough to create the
needed
momentum, and we would need to be willing to create packages diverging from the
Juniper ones if it's necessary to stay compliant with the Debian and Ubuntu
policies.
I'm thinking of stuff such as upstart/systemd integration.
Please let me know what you think.
Best regards
Martin
_______________________________________________
Dev mailing list
[email protected]
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
