Hi,
It is now time for sig-configmanagement member to discuss and open bug
requests on bugs.centos.org about CBS tag requests.
CBS: https://wiki.centos.org/HowTos/CommunityBuildSystem
How to: https://wiki.centos.org/HowTos/CentosPackager
Bug requests to create new tags need to be open under the buildsys
category.
This is the bug request I opened for Puppet and common tags:
https://bugs.centos.org/view.php?id=10604
I would also like that any member plays with CBS by trying to make
scratch builds to CBS. I encourage you to make scratch builds in the "bananas" tags.
! Please ask for help it anything is not clear. It would be great if as
much people could test CBS before the next meeting and ask for tags.
--
(o- Julien Pivotto
//\ Config Management SIG
V_/_ https://frama.link/cfgmgmt
Hi all,
For the Config Management SIG, we will need to rebuild some EPEL
packages. However, we do not want to rebuild them 'as it' because we do
not want to depend on EPEL version etc. EPEL is not always "stable" and
we do not want our users to be in troubles regarding EPEL decisions
(https://lists.centos.org/pipermail/centos-devel/2015-December/014101.html)
Some projects use Python or Ruby librairies that we could also put in a
SCL.
What prefix should we use for those SCL?
Some ideas:
/opt/centos/
/opt/centos-sig-configmanagement
/opt/centos/sig-configmanagement
Thanks for your feedback.
--
(o- Julien Pivotto
//\ Config Management SIG
V_/_ https://frama.link/cfgmgmt
Hi,
I was expecting the SIG meetings to be shifted by one hour due to DST.
However, that is not possible because the pass-sig meetings are not DST
affected.
I will NOT be able to join the next meeting, because I was expecting it
to be held one hour earlier.
The date of the next meeting is:
date -d 'Wed Apr 13 16:00:00 UTC 2016'
(Wed Apr 13 18:00:00 CEST 2016)
Another member of the sig will need to take the lead of the meeting.
--
(o- Julien Pivotto
//\ Config Management SIG
V_/_ https://frama.link/cfgmgmt
Hello,
It's time for our weekly PaaS SIG sync-up meeting
Time: 1500 UTC - Wedensdays
Date: Today Wedensday, 06 April 2016
Where: IRC- Freenode - #centos-devel
Agenda:
- OpenShift Current Status
-- rpms - origin 1.1.6, docker 1.9.1-origin
-- repo(s)
--- https://tdawson.fedorapeople.org/centos/CentOS-OpenShift.repo
--- testing (buildlogs)
--- candidate
-- images - not started
-- Quickstart - not started
- What is our criteria for a release?
- Building image demo ??
- Open Floor
hi,
I've just done a complete rehash of all the buildlogs repos from their
corresponding cbs.centos.org tag's, please let me know if there are any
issues. It does mean a lot of the older stale content will be gone (
saving us 50+ GB )
Regards
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
hi Guys,
We've made some progress on the Pipeline bringup. Highlights from the
last few days:
- Welcome Dharmit to the team, he's going to be contributing on the
testing side of things.
- We've got some baseline user stories written up, in the coming days
the aim is to try and get some acceptance criteria written up, following
which we will try and do some estimates and task allocations around
them. We'll then get these in front of a larger audience to see how
things map to expectations and what folks feel is the best priority
order to work on.
- Within our devel infra, we've established an idea of Project V/s Job.
Users will now have their built containers delivered as
<hostname>/<project name>/<job id>:<tag>
- We've got a test instance up for pulp 2.8, that seems to meet all the
requirements of delivering both a v1 and v2 container format; although
we are likely only going to be looking at v2 from now onwards.
- We've started working on a deploy script that would allow us to run
managed deploy's and also help us move into a CD like setup, where we
can test / deploy often.
- Hardware to locate the first user facing version of the stack is now
in place, and we have the required firewall policy etc setup. In the
coming days, we will start doing some load testing and also start
working through the implementation plans for the user service.
Most of our effort is now focused on getting the content together to
have a user facing deployment up.
Regards
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
I've corresponded with KS in the past regarding the vagrant images (thanks!) but wanted to this to the list to request the vagrant images be tweaked a little in future updates:
* the /boot partition is too small - starting with a current vagrant image, just one kernel update resulted in complaints about /boot being too full. Can we consider adding 100MB to the /boot size and changing the installonly_limit in yum.conf down to perhaps 2 to try to live in a tiny /boot without users needing to work that hard after a simple yum update
The manual steps in https://unix.stackexchange.com/questions/105026 work ok, as one way to work around it manually.
* there is no DVD device defined, making it painful to install VirtualBox guest additions. At a minimum the box should have the device defined there so users don't have to work so hard if they update their kernel.
Possible workarounds including adding a vagrant plugin (https://github.com/dotless-de/vagrant-vbguest) to automate reinstalling the guest additions pretty nicely.
Other workaround is to manually add the device in your Vagrantfile using vb.customize ala:
Vagrant.configure(2) do |config|
config.vm.box = "centos/7"
config.vm.provider "virtualbox" do |vb|
vb.gui = true
vb.memory = "1024"
vb.customize "pre-boot", [
"storageattach", :id,
"--storagectl", "IDE Controller",
"--port", "1",
"--device", "0",
"--type", "dvddrive",
"--medium", "emptydrive",
]
vb.customize ["modifyvm", :id, "--clipboard", "bidirectional"]
vb.customize ["modifyvm", :id, "--draganddrop", "bidirectional"]
end
config.vm.provision "shell", path: "provision.sh"
end
I'm bringing it up only because these images are 'so' good already, it would be fabulous if no workarounds were needed out of the box.
Thanks again for the rolling vagrant/docker/AMI images - much appreciated. They really help.
--
Vince Skahan
Infrastructure Engineering and Support
Office of Research Information Services (ORIS)