Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-19 Thread Ian Wienand 

On 02/20/2018 02:23 AM, Paul Belanger wrote:

Why not just split the builder configuration file? I don't see a
need to add code to do this.


I'm happy with this; I was just coming at it from an angle of not
splitting the config file, but KISS :)


I did submit support homing diskimage builds to specific builder[2] a while
back, which is more inline with what ianw is asking. This allows us to assign
images to builders, if set.



[2] https://review.openstack.org/461239/


Only comment on this is that I think it might be better to avoid
putting specific hostnames in there directly; but rather add meta-data
to diskimage configurations describing the features they need on the
builder, and have the builder then only choose those builds it knows
it can do.  Feels more natural for the message-queue/scale-out type
environment where we can add/drop hosts at will.

We've two real examples to inform design; needing the Xenial build
host when all the others were trusty, and now the arm64 based ones.

-i

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-19 Thread David Shrewsbury 
On Mon, Feb 19, 2018 at 10:23 AM, Paul Belanger 
wrote:

> On Mon, Feb 19, 2018 at 08:28:27AM -0500, David Shrewsbury wrote:
> > Hi,
> >
> > On Sun, Feb 18, 2018 at 10:25 PM, Ian Wienand 
> wrote:
> >
> > > Hi,
> > >
> > > How should we go about restricting certain image builds to specific
> > > nodepool builder instances?  My immediate issue is with ARM64 image
> > > builds, which I only want to happen on a builder hosted in an ARM64
> > > cloud.
> > >
> > > Currently, the builders go through the image list and check "is the
> > > existing image missing or too old, if so, build" [1].  Additionally,
> > > all builders share a configuration file [2]; so builders don't know
> > > "who they are".
> > >
> > >
> >
> > Why not just split the builder configuration file? I don't see a need to
> > add code
> > to do this.
> >
> In our case (openstack-infra) this will require another change to
> puppet-nodepool to support this. Not that we cannot, but it will now mean
> we'll
> have 7[1] different nodepool configuration files to now manage. 4 x
> nodepool-launchers, 3 x nodepool-builders, since we have 7 services
> running.
>

We don't have to have 1 config file per builder. Just one additional file
for the
arm64 builder. The others can still share the config we have now.


-Dave
-- 
David Shrewsbury (Shrews)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-19 Thread James E. Blair 
Paul Belanger  writes:

> On Mon, Feb 19, 2018 at 08:28:27AM -0500, David Shrewsbury wrote:
>> Hi,
>> 
>> On Sun, Feb 18, 2018 at 10:25 PM, Ian Wienand  wrote:
>> 
>> > Hi,
>> >
>> > How should we go about restricting certain image builds to specific
>> > nodepool builder instances?  My immediate issue is with ARM64 image
>> > builds, which I only want to happen on a builder hosted in an ARM64
>> > cloud.
>> >
>> > Currently, the builders go through the image list and check "is the
>> > existing image missing or too old, if so, build" [1].  Additionally,
>> > all builders share a configuration file [2]; so builders don't know
>> > "who they are".
>> >
>> >
>> 
>> Why not just split the builder configuration file? I don't see a need to
>> add code
>> to do this.
>> 
> In our case (openstack-infra) this will require another change to
> puppet-nodepool to support this. Not that we cannot, but it will now mean 
> we'll
> have 7[1] different nodepool configuration files to now manage. 4 x
> nodepool-launchers, 3 x nodepool-builders, since we have 7 services running.

This seems like a pretty legitimate case to split the config.  Very
little of the config for the arm64 builder will be shared with any of
the other builders, so perhaps unlike the case where one simply wants
high-availability launchers, this seems like a very sensible use of a
separate config file.

At any rate, that's what we should do in openstack-infra to solve the
issue Ian asked about.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-19 Thread Paul Belanger 
On Mon, Feb 19, 2018 at 08:28:27AM -0500, David Shrewsbury wrote:
> Hi,
> 
> On Sun, Feb 18, 2018 at 10:25 PM, Ian Wienand  wrote:
> 
> > Hi,
> >
> > How should we go about restricting certain image builds to specific
> > nodepool builder instances?  My immediate issue is with ARM64 image
> > builds, which I only want to happen on a builder hosted in an ARM64
> > cloud.
> >
> > Currently, the builders go through the image list and check "is the
> > existing image missing or too old, if so, build" [1].  Additionally,
> > all builders share a configuration file [2]; so builders don't know
> > "who they are".
> >
> >
> 
> Why not just split the builder configuration file? I don't see a need to
> add code
> to do this.
> 
In our case (openstack-infra) this will require another change to
puppet-nodepool to support this. Not that we cannot, but it will now mean we'll
have 7[1] different nodepool configuration files to now manage. 4 x
nodepool-launchers, 3 x nodepool-builders, since we have 7 services running.

We could update puppet to start templating or add support for nodepool.d (like
zuul.d) and better split our configs too. I just haven't found time to write
that patch.

I did submit support homing diskimage builds to specific builder[2] a while
back, which is more inline with what ianw is asking. This allows us to assign
images to builders, if set.

[1] http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool
[2] https://review.openstack.org/461239/
> 
> 
> 
> > I'd propose we add an arbitrary tag/match system so that builders can
> > pickup only those builds they mark themselves capable of building?
> >
> > e.g. diskimages would specify required builder tags similar to:
> >
> > ---
> > diskimages:
> >   - name: arm64-ubuntu-xenial
> > elements:
> >   - block-device-efi
> >   - vm
> >   - ubuntu-minimal
> >   ...
> > env-vars:
> >   TMPDIR: /opt/dib_tmp
> >   DIB_CHECKSUM: '1'
> >   ...
> > builder-requires:
> >   architecture: arm64
> > ---
> >
> > The nodepool.yaml would grow another section similar:
> >
> > ---
> > builder-provides:
> >   architecture: arm64
> >   something_else_unique_about_this_buidler: true
> > ---
> >
> > For OpenStack, we would template this section in the config file via
> > puppet in [2], ensuring above that only our theoretical ARM64 build
> > machine had that section in it's config.
> >
> > The nodepool-buidler build loop can then check that its
> > builder-provides section has all the tags specified in an image's
> > "builder-requires" section before deciding to start building.
> >
> > Thoughts welcome :)
> >
> > -i
> >
> > [1] https://git.openstack.org/cgit/openstack-infra/nodepool/
> > tree/nodepool/builder.py#n607
> > [2] https://git.openstack.org/cgit/openstack-infra/project-
> > config/tree/nodepool/nodepool.yaml
> >
> > ___
> > Zuul-discuss mailing list
> > zuul-disc...@lists.zuul-ci.org
> > http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
> >
> 
> 
> 
> -- 
> David Shrewsbury (Shrews)

> ___
> Zuul-discuss mailing list
> zuul-disc...@lists.zuul-ci.org
> http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-19 Thread David Shrewsbury 
Hi,

On Sun, Feb 18, 2018 at 10:25 PM, Ian Wienand  wrote:

> Hi,
>
> How should we go about restricting certain image builds to specific
> nodepool builder instances?  My immediate issue is with ARM64 image
> builds, which I only want to happen on a builder hosted in an ARM64
> cloud.
>
> Currently, the builders go through the image list and check "is the
> existing image missing or too old, if so, build" [1].  Additionally,
> all builders share a configuration file [2]; so builders don't know
> "who they are".
>
>

Why not just split the builder configuration file? I don't see a need to
add code
to do this.




> I'd propose we add an arbitrary tag/match system so that builders can
> pickup only those builds they mark themselves capable of building?
>
> e.g. diskimages would specify required builder tags similar to:
>
> ---
> diskimages:
>   - name: arm64-ubuntu-xenial
> elements:
>   - block-device-efi
>   - vm
>   - ubuntu-minimal
>   ...
> env-vars:
>   TMPDIR: /opt/dib_tmp
>   DIB_CHECKSUM: '1'
>   ...
> builder-requires:
>   architecture: arm64
> ---
>
> The nodepool.yaml would grow another section similar:
>
> ---
> builder-provides:
>   architecture: arm64
>   something_else_unique_about_this_buidler: true
> ---
>
> For OpenStack, we would template this section in the config file via
> puppet in [2], ensuring above that only our theoretical ARM64 build
> machine had that section in it's config.
>
> The nodepool-buidler build loop can then check that its
> builder-provides section has all the tags specified in an image's
> "builder-requires" section before deciding to start building.
>
> Thoughts welcome :)
>
> -i
>
> [1] https://git.openstack.org/cgit/openstack-infra/nodepool/
> tree/nodepool/builder.py#n607
> [2] https://git.openstack.org/cgit/openstack-infra/project-
> config/tree/nodepool/nodepool.yaml
>
> ___
> Zuul-discuss mailing list
> zuul-disc...@lists.zuul-ci.org
> http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
>



-- 
David Shrewsbury (Shrews)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [nodepool] Restricting images to specific nodepool builders

2018-02-18 Thread remo 
Content-Type: multipart/alternative;
 boundary="=_5837c9f000872ae1dfc7317ed2bea8a3"



--=_5837c9f000872ae1dfc7317ed2bea8a3

Content-Transfer-Encoding: base64

Content-Type: text/plain; charset=utf-8



WW91IHByb2JhYmx5IG5lZWQgdG8gY2hhbmdlIHBvbGljeS5qc29uIGFuZCBjcmVhdGUgc29tZSBy

dWxlcyB0aGVyZSB3aXRoIGF6IG9wdGlvbnMuIA0KDQrvo78gZGFsIG1pbyBpUGhvbmUgWCANCg0K

PiBJbCBnaW9ybm8gMTggZmViIDIwMTgsIGFsbGUgb3JlIDE5OjI1LCBJYW4gV2llbmFuZCA8aXdp

ZW5hbmRAcmVkaGF0LmNvbT4gaGEgc2NyaXR0bzoNCj4gDQo+IEhpLA0KPiANCj4gSG93IHNob3Vs

ZCB3ZSBnbyBhYm91dCByZXN0cmljdGluZyBjZXJ0YWluIGltYWdlIGJ1aWxkcyB0byBzcGVjaWZp

Yw0KPiBub2RlcG9vbCBidWlsZGVyIGluc3RhbmNlcz8gIE15IGltbWVkaWF0ZSBpc3N1ZSBpcyB3

aXRoIEFSTTY0IGltYWdlDQo+IGJ1aWxkcywgd2hpY2ggSSBvbmx5IHdhbnQgdG8gaGFwcGVuIG9u

IGEgYnVpbGRlciBob3N0ZWQgaW4gYW4gQVJNNjQNCj4gY2xvdWQuDQo+IA0KPiBDdXJyZW50bHks

IHRoZSBidWlsZGVycyBnbyB0aHJvdWdoIHRoZSBpbWFnZSBsaXN0IGFuZCBjaGVjayAiaXMgdGhl

DQo+IGV4aXN0aW5nIGltYWdlIG1pc3Npbmcgb3IgdG9vIG9sZCwgaWYgc28sIGJ1aWxkIiBbMV0u

ICBBZGRpdGlvbmFsbHksDQo+IGFsbCBidWlsZGVycyBzaGFyZSBhIGNvbmZpZ3VyYXRpb24gZmls

ZSBbMl07IHNvIGJ1aWxkZXJzIGRvbid0IGtub3cNCj4gIndobyB0aGV5IGFyZSIuDQo+IA0KPiBJ

J2QgcHJvcG9zZSB3ZSBhZGQgYW4gYXJiaXRyYXJ5IHRhZy9tYXRjaCBzeXN0ZW0gc28gdGhhdCBi

dWlsZGVycyBjYW4NCj4gcGlja3VwIG9ubHkgdGhvc2UgYnVpbGRzIHRoZXkgbWFyayB0aGVtc2Vs

dmVzIGNhcGFibGUgb2YgYnVpbGRpbmc/DQo+IA0KPiBlLmcuIGRpc2tpbWFnZXMgd291bGQgc3Bl

Y2lmeSByZXF1aXJlZCBidWlsZGVyIHRhZ3Mgc2ltaWxhciB0bzoNCj4gDQo+IC0tLQ0KPiBkaXNr

aW1hZ2VzOg0KPiAgLSBuYW1lOiBhcm02NC11YnVudHUteGVuaWFsDQo+ICAgIGVsZW1lbnRzOg0K

PiAgICAgIC0gYmxvY2stZGV2aWNlLWVmaQ0KPiAgICAgIC0gdm0NCj4gICAgICAtIHVidW50dS1t

aW5pbWFsDQo+ICAgICAgLi4uDQo+ICAgIGVudi12YXJzOg0KPiAgICAgIFRNUERJUjogL29wdC9k

aWJfdG1wDQo+ICAgICAgRElCX0NIRUNLU1VNOiAnMScNCj4gICAgICAuLi4NCj4gICAgYnVpbGRl

ci1yZXF1aXJlczoNCj4gICAgICBhcmNoaXRlY3R1cmU6IGFybTY0DQo+IC0tLQ0KPiANCj4gVGhl

IG5vZGVwb29sLnlhbWwgd291bGQgZ3JvdyBhbm90aGVyIHNlY3Rpb24gc2ltaWxhcjoNCj4gDQo+

IC0tLQ0KPiBidWlsZGVyLXByb3ZpZGVzOg0KPiAgYXJjaGl0ZWN0dXJlOiBhcm02NA0KPiAgc29t

ZXRoaW5nX2Vsc2VfdW5pcXVlX2Fib3V0X3RoaXNfYnVpZGxlcjogdHJ1ZQ0KPiAtLS0NCj4gDQo+

IEZvciBPcGVuU3RhY2ssIHdlIHdvdWxkIHRlbXBsYXRlIHRoaXMgc2VjdGlvbiBpbiB0aGUgY29u

ZmlnIGZpbGUgdmlhDQo+IHB1cHBldCBpbiBbMl0sIGVuc3VyaW5nIGFib3ZlIHRoYXQgb25seSBv

dXIgdGhlb3JldGljYWwgQVJNNjQgYnVpbGQNCj4gbWFjaGluZSBoYWQgdGhhdCBzZWN0aW9uIGlu

IGl0J3MgY29uZmlnLg0KPiANCj4gVGhlIG5vZGVwb29sLWJ1aWRsZXIgYnVpbGQgbG9vcCBjYW4g

dGhlbiBjaGVjayB0aGF0IGl0cw0KPiBidWlsZGVyLXByb3ZpZGVzIHNlY3Rpb24gaGFzIGFsbCB0

aGUgdGFncyBzcGVjaWZpZWQgaW4gYW4gaW1hZ2Uncw0KPiAiYnVpbGRlci1yZXF1aXJlcyIgc2Vj

dGlvbiBiZWZvcmUgZGVjaWRpbmcgdG8gc3RhcnQgYnVpbGRpbmcuDQo+IA0KPiBUaG91Z2h0cyB3

ZWxjb21lIDopDQo+IA0KPiAtaQ0KPiANCj4gWzFdIGh0dHBzOi8vZ2l0Lm9wZW5zdGFjay5vcmcv

Y2dpdC9vcGVuc3RhY2staW5mcmEvbm9kZXBvb2wvdHJlZS9ub2RlcG9vbC9idWlsZGVyLnB5I242

MDcNCj4gWzJdIGh0dHBzOi8vZ2l0Lm9wZW5zdGFjay5vcmcvY2dpdC9vcGVuc3RhY2staW5mcmEv

cHJvamVjdC1jb25maWcvdHJlZS9ub2RlcG9vbC9ub2RlcG9vbC55YW1sDQo+IA0KPiBfX19fX19f

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPcGVuU3RhY2stSW5m

cmEgbWFpbGluZyBsaXN0DQo+IE9wZW5TdGFjay1JbmZyYUBsaXN0cy5vcGVuc3RhY2sub3JnDQo+

IGh0dHA6Ly9saXN0cy5vcGVuc3RhY2sub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9vcGVu

c3RhY2staW5mcmENCg==

--=_5837c9f000872ae1dfc7317ed2bea8a3--


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra