Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development: - Support Fedora Images (https://bugs.centos.org/view.php?id=13626) - Support for cloud VMs in cloud.ci.centos.org - Support for VLAN Isolation on the Seamicro hardware - Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
If you're interested in participating in the development effort, please get in touch with me.
Happy Testing!
-- Brian Stinson CentOS CI Infrastructure Team
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
On Aug 22 11:26, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
Would some proportion of free space in the primary volume group be sufficient for your needs, or do you need bare partitions?
--Brian
On Tue, Aug 22, 2017 at 09:36:04PM -0500, Brian Stinson wrote:
On Aug 22 11:26, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
Would some proportion of free space in the primary volume group be sufficient for your needs, or do you need bare partitions?
A bare partition would be better. For snapshots of Gluster volumes we use LVM thin-provisioning and need to setup a VG for that. There is also work in progress to support btrfs snapshots, and I dont think we should place those on a PV either.
Niels
On 23/08/17 08:57, Niels de Vos wrote:
On Tue, Aug 22, 2017 at 09:36:04PM -0500, Brian Stinson wrote:
On Aug 22 11:26, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
Would some proportion of free space in the primary volume group be sufficient for your needs, or do you need bare partitions?
A bare partition would be better. For snapshots of Gluster volumes we use LVM thin-provisioning and need to setup a VG for that. There is also work in progress to support btrfs snapshots, and I dont think we should place those on a PV either.
can be accomodated with something like an on-demand install / provision where you can parameterise the kickstart itself, but the flip side is ~ 5 min wait for the machine to become available.
On 08/22/2017 06:26 AM, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
This feature would also be handy to test partition programs, e.g., blivet and friends.
Allowing user to specify disk features, for example, block size (512 vs. 4096 bytes) and capacity (1G vs. 10G) would also be nice to have.
On Aug 23 19:51, Murilo Opsfelder Araújo wrote:
On 08/22/2017 06:26 AM, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
This feature would also be handy to test partition programs, e.g., blivet and friends.
Allowing user to specify disk features, for example, block size (512 vs. 4096 bytes) and capacity (1G vs. 10G) would also be nice to have.
-- Murilo
Great discussion so far, Tracking this here: https://bugs.centos.org/view.php?id=13708
On 23/08/17 23:51, Murilo Opsfelder Araújo wrote:
On 08/22/2017 06:26 AM, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
This feature would also be handy to test partition programs, e.g., blivet and friends.
Allowing user to specify disk features, for example, block size (512 vs. 4096 bytes) and capacity (1G vs. 10G) would also be nice to have.
ofcourse, with a little bit of gymnastics, you can already do this today :)
what would be good to see described, and maybe something for Brian, is to get the workflow documented for something like this. How I am seeing this now is that its a case of a custom ks used at deploy time, which in turn is from a different call ( eg. not a /node/get ), and comes with a latency question ( ~ 5 min to 10 min ). What needs working out is how the session management is then done.
maybe something like this : - session is allocated at the time a call is made ( with no hosts attached ) - machine(s0 are provisioned - session is populated at the duffy end, with the client ( user / cico_client etc ) needing to poll for details, say every 60 seconds.
does that sound about right ?
On Aug 24 13:23, Karanbir Singh wrote:
On 23/08/17 23:51, Murilo Opsfelder Araújo wrote:
On 08/22/2017 06:26 AM, Niels de Vos wrote:
On Mon, Aug 21, 2017 at 09:55:46PM -0500, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
It would be helpful to have an option for keeping extras disks (or a partition) available for free-to-use storage. This can help testing features in Gluster (and probably Ceph) that require a block device. We currently work around that with disk-images/losetup kind of approaches, but it is definitely not how actual deployments are expected to be done.
Thanks, Niels
This feature would also be handy to test partition programs, e.g., blivet and friends.
Allowing user to specify disk features, for example, block size (512 vs. 4096 bytes) and capacity (1G vs. 10G) would also be nice to have.
ofcourse, with a little bit of gymnastics, you can already do this today :)
what would be good to see described, and maybe something for Brian, is to get the workflow documented for something like this. How I am seeing this now is that its a case of a custom ks used at deploy time, which in turn is from a different call ( eg. not a /node/get ), and comes with a latency question ( ~ 5 min to 10 min ). What needs working out is how the session management is then done.
maybe something like this :
- session is allocated at the time a call is made ( with no hosts attached )
- machine(s0 are provisioned
- session is populated at the duffy end, with the client ( user /
cico_client etc ) needing to poll for details, say every 60 seconds.
does that sound about right ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
Implementation is something to discuss when we get to actually planning the development. There's an RFE tracked: https://bugs.centos.org/view.php?id=13708
These are things I'd love to see fixed:
* Request nodes in specific chasis, for instance, if we're trying to test performance and want a continuous baseline. * Given that Duffy v2 is going to be open source, is there going to be a tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
On Tue, Aug 22, 2017 at 8:25 AM, Brian Stinson brian@bstinson.com wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
If you're interested in participating in the development effort, please get in touch with me.
Happy Testing!
-- Brian Stinson CentOS CI Infrastructure Team _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
On Aug 22 16:24, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to test
performance and want a continuous baseline.
I'm -0 (but I'm pretty easily convinced :) on this, specifically because we may not have the 'chassis' abstraction to select on if/when the seamicros go away.
Your performance differences were in AMD vs. Intel, correct?
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
If you're interested, we certainly won't say no! It would be good to have another installation to keep us 'honest' (so to speak) in making sure we follow good practices.
On Tue, Aug 22, 2017 at 8:25 AM, Brian Stinson brian@bstinson.com wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
If you're interested in participating in the development effort, please get in touch with me.
Happy Testing!
-- Brian Stinson CentOS CI Infrastructure Team _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
-- nigelb
On Wed, Aug 23, 2017 at 8:16 AM, Brian Stinson brian@bstinson.com wrote:
On Aug 22 16:24, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to test
performance and want a continuous baseline.
I'm -0 (but I'm pretty easily convinced :) on this, specifically because we may not have the 'chassis' abstraction to select on if/when the seamicros go away.
Your performance differences were in AMD vs. Intel, correct?
Indeed. If we classify the machines into different types, and we can request the same types, that works too. I believe it was also a difference of RAM as well.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
If you're interested, we certainly won't say no! It would be good to have another installation to keep us 'honest' (so to speak) in making sure we follow good practices.
There are times when I wished we had a Duffy like API for our machines which would create and destroy on request. Except we'd have VMs and not physical machines.
On Aug 23 08:46, Nigel Babu wrote:
On Wed, Aug 23, 2017 at 8:16 AM, Brian Stinson brian@bstinson.com wrote:
On Aug 22 16:24, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to test
performance and want a continuous baseline.
I'm -0 (but I'm pretty easily convinced :) on this, specifically because we may not have the 'chassis' abstraction to select on if/when the seamicros go away.
Your performance differences were in AMD vs. Intel, correct?
Indeed. If we classify the machines into different types, and we can request the same types, that works too. I believe it was also a difference of RAM as well.
For the Seamicros, we should be homogenous on RAM now (our less-dense chassis is now a test system).
Tracking ticket: https://bugs.centos.org/view.php?id=13709
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
If you're interested, we certainly won't say no! It would be good to have another installation to keep us 'honest' (so to speak) in making sure we follow good practices.
There are times when I wished we had a Duffy like API for our machines which would create and destroy on request. Except we'd have VMs and not physical machines.
Cool, what type of VMs are you looking at?
For duffy we're targeting libvirt (temporarily), and openstack (longer term).
On 22/08/17 11:54, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to
test performance and want a continuous baseline.
This is pretty hard to achieve, since it means predicting binpacking on clusters. I've tried this in the past, and as a best effort was only able to get about 20 - 25 hitrate, but happy to revisit.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
absolutely.
On Tue, Aug 22, 2017 at 8:25 AM, Brian Stinson <brian@bstinson.com mailto:brian@bstinson.com> wrote:
Hi Folks, You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy <https://wiki.centos.org/QaWiki/CI/Duffy>). In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository. Some of you have pending RFEs that we'll deal with during development: - Support Fedora Images (https://bugs.centos.org/view.php?id=13626 <https://bugs.centos.org/view.php?id=13626>) - Support for cloud VMs in cloud.ci.centos.org <http://cloud.ci.centos.org> - Support for VLAN Isolation on the Seamicro hardware - Support for extending an existing session (https://bugs.centos.org/view.php?id=9773 <https://bugs.centos.org/view.php?id=9773>) If you have a feature request for us to track let's talk about it here. If you're interested in participating in the development effort, please get in touch with me. Happy Testing! -- Brian Stinson CentOS CI Infrastructure Team _______________________________________________ Ci-users mailing list Ci-users@centos.org <mailto:Ci-users@centos.org> https://lists.centos.org/mailman/listinfo/ci-users <https://lists.centos.org/mailman/listinfo/ci-users>-- nigelb
Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
On 08/22/2017 07:54 AM, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to
test performance and want a continuous baseline.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
Automating the deployment of a Duffy server with Ansible would be nice too.
If Duffy server can be deployed on a distro-agnostic box, that'd be even better.
Talking about distros, is there any plan to provision/serve non-rpm distros? My bet is no. I think that should be in mind just not to couple things on rpm only.
On Aug 23 20:02, Murilo Opsfelder Araújo wrote:
On 08/22/2017 07:54 AM, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to
test performance and want a continuous baseline.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
Automating the deployment of a Duffy server with Ansible would be nice too.
This should be handled by the client side of the house, cicoclient: https://github.com/CentOS/python-cicoclient
can provision using ansible, and we'll continue using cicoclient as our client reference implementation for duffy2.
If Duffy server can be deployed on a distro-agnostic box, that'd be even better.
Talking about distros, is there any plan to provision/serve non-rpm distros? My bet is no. I think that should be in mind just not to couple things on rpm only.
RPM distros are much easier for us, and we have enough folks requesting Fedora that I think we can consider doing that much.
Would a 'bring-your-own-image' scenario to provision openstack VMs be sufficient for this case?
On Aug 23 19:23, Brian Stinson wrote:
On Aug 23 20:02, Murilo Opsfelder Araújo wrote:
On 08/22/2017 07:54 AM, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to
test performance and want a continuous baseline.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
Automating the deployment of a Duffy server with Ansible would be nice too.
This should be handled by the client side of the house, cicoclient: https://github.com/CentOS/python-cicoclient
can provision using ansible, and we'll continue using cicoclient as our client reference implementation for duffy2.
And of course, now I'm realizing that you may have meant deploying the duffy service itself using ansible, in which case: also yes! We'll be opening up the ansible roles we use in CICO to get duffy up and running.
If Duffy server can be deployed on a distro-agnostic box, that'd be even better.
Talking about distros, is there any plan to provision/serve non-rpm distros? My bet is no. I think that should be in mind just not to couple things on rpm only.
RPM distros are much easier for us, and we have enough folks requesting Fedora that I think we can consider doing that much.
Would a 'bring-your-own-image' scenario to provision openstack VMs be sufficient for this case?
On 24/08/17 01:43, Brian Stinson wrote:
On Aug 23 19:23, Brian Stinson wrote:
On Aug 23 20:02, Murilo Opsfelder Araújo wrote:
On 08/22/2017 07:54 AM, Nigel Babu wrote:
These are things I'd love to see fixed:
- Request nodes in specific chasis, for instance, if we're trying to
test performance and want a continuous baseline.
- Given that Duffy v2 is going to be open source, is there going to be a
tiny focus on someone who's not CentOS CI being able to deploy it? (I'm happy to be involved to do this)
Automating the deployment of a Duffy server with Ansible would be nice too.
This should be handled by the client side of the house, cicoclient: https://github.com/CentOS/python-cicoclient
can provision using ansible, and we'll continue using cicoclient as our client reference implementation for duffy2.
And of course, now I'm realizing that you may have meant deploying the duffy service itself using ansible, in which case: also yes! We'll be opening up the ansible roles we use in CICO to get duffy up and running.
tempted to just go openshift for duffy2 here, then its just a single manifest to apply ( and local instances can be either minishift or a 'oc cluster up' setup )
On 08/23/2017 09:43 PM, Brian Stinson wrote:
And of course, now I'm realizing that you may have meant deploying the duffy service itself using ansible, in which case: also yes! We'll be opening up the ansible roles we use in CICO to get duffy up and running.
That's great!
On 08/23/2017 09:23 PM, Brian Stinson wrote:
RPM distros are much easier for us, and we have enough folks requesting Fedora that I think we can consider doing that much.
Would a 'bring-your-own-image' scenario to provision openstack VMs be sufficient for this case?
I think that would fit. Perhaps user could specify the download location of that image when calling the Duffy API.
On 22/08/17 03:55, Brian Stinson wrote:
If you have a feature request for us to track let's talk about it here.
been thinking through creds a bit this morning.
Duffy already sets up the user / label key so that the jobs can ssh into the remote host and do what they need to do. I am wondering if we can extend this to also cover other credentials that jobs might need. and plug in something like hash vault that then allows users to self-manage their creds, and have them auto available in the sessions on the remote hosts.
as an example, something extremely simple, like a key value file, sourced in the .bashrc of the remote shell would give you whatever is labelled for the tenant, in place.
On Aug 24 13:56, Karanbir Singh wrote:
On 22/08/17 03:55, Brian Stinson wrote:
If you have a feature request for us to track let's talk about it here.
been thinking through creds a bit this morning.
Duffy already sets up the user / label key so that the jobs can ssh into the remote host and do what they need to do. I am wondering if we can extend this to also cover other credentials that jobs might need. and plug in something like hash vault that then allows users to self-manage their creds, and have them auto available in the sessions on the remote hosts.
as an example, something extremely simple, like a key value file, sourced in the .bashrc of the remote shell would give you whatever is labelled for the tenant, in place.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
Are there specific developers asking for this? Who is best to help us with the acceptance criteria?
I don't want to go too far down the implementation path for this until we know what they need. That will also help answer the question of if Duffy is the right place for this.
On 08/24/2017 09:56 AM, Karanbir Singh wrote:
On 22/08/17 03:55, Brian Stinson wrote:
If you have a feature request for us to track let's talk about it here.
been thinking through creds a bit this morning.
Duffy already sets up the user / label key so that the jobs can ssh into the remote host and do what they need to do. I am wondering if we can extend this to also cover other credentials that jobs might need. and plug in something like hash vault that then allows users to self-manage their creds, and have them auto available in the sessions on the remote hosts.
as an example, something extremely simple, like a key value file, sourced in the .bashrc of the remote shell would give you whatever is labelled for the tenant, in place.
For these kind of settings to be applied on nodes, I think Duffy API could allow user specifying a file location containing a cloud-init configuration, or a kickstart snippet, or a raw shell script to be executed.
For example:
$ cico node get --arch ppc64le --release 7 --count 1 --post-setup cloud-init=http://domain.tld/cloud-init-config.txt
$ cico node get --arch ppc64le --release 7 --count 1 --post-setup kickstart=http://domain.tld/config.ks
$ cico node get --arch ppc64le --release 7 --count 1 --post-setup shell=http://domain.tld/post-setup-commands.txt
So all the customization is delegated to the user. Duffy would just need to know if it has to run cloud-init, kickstart, or shell script.
A benefit of allowing cloud-init configuration is that users from OpenStack would need very few or none effort to update their cloud-init settings to use with Duffy.
I'm having an idea of testing container images in OpenShift just after the container image itself is built&tested. For that we may use either `oc cluster up` or minishift, but installing both means to pull a lot of MB.
So, I'm thinking about whether it would make sense to have an option to request a machine with `oc` already available -- basically a machine where the openshift containers are already up and running.. and tests would only depend on `oc` being available.
Would something like that make sense for anybody else as well? And would the bandwidth saved for pulling the openshift images be worth it?
Honza
On 08/22/2017 04:55 AM, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
If you're interested in participating in the development effort, please get in touch with me.
Happy Testing!
-- Brian Stinson CentOS CI Infrastructure Team _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
On Aug 28 08:22, Honza Horak wrote:
I'm having an idea of testing container images in OpenShift just after the container image itself is built&tested. For that we may use either `oc cluster up` or minishift, but installing both means to pull a lot of MB.
So, I'm thinking about whether it would make sense to have an option to request a machine with `oc` already available -- basically a machine where the openshift containers are already up and running.. and tests would only depend on `oc` being available.
Would something like that make sense for anybody else as well? And would the bandwidth saved for pulling the openshift images be worth it?
Not sure if bandwidth is the controlling factor here, but we could colocate a mirror to help with that side of things. Also, https://registry.centos.org is pretty close by as well.
If needing a one-off openshift a common enough pattern, we could look at adding minishift as a 'thing' in duffy, so instead of bare nodes you'd request an openshift install.
If I point you at a RFE, could you help write the acceptance criteria? https://bugs.centos.org/view.php?id=13728
Honza
On 08/22/2017 04:55 AM, Brian Stinson wrote:
Hi Folks,
You're likely familiar with our node provisioner Duffy (https://wiki.centos.org/QaWiki/CI/Duffy).
In order to support new features, and encourage interested folks to participate in development with us, we are gathering requirements to get started soon on Duffy Version 2. Duffy2 will be developed with an OSS license, and posted in a public repository.
Some of you have pending RFEs that we'll deal with during development:
- Support Fedora Images (https://bugs.centos.org/view.php?id=13626)
- Support for cloud VMs in cloud.ci.centos.org
- Support for VLAN Isolation on the Seamicro hardware
- Support for extending an existing session (https://bugs.centos.org/view.php?id=9773)
If you have a feature request for us to track let's talk about it here.
If you're interested in participating in the development effort, please get in touch with me.
Happy Testing!
-- Brian Stinson CentOS CI Infrastructure Team _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
-
Brian Stinson -
Honza Horak -
Karanbir Singh -
Murilo Opsfelder Araújo -
Niels de Vos -
Nigel Babu