devel November 2014

devel@lists.centos.org

55 participants
51 discussions

cbs feature req: building embargoed content
by Karanbir Singh 12 Mar '15

12 Mar '15

hi guys, we need a way to build embargo'd content like reimzul's priv-build, that does not make stuff public till a specific date ( the actual push to public can be manual ); how would we achieve this on cbs ? I guess the git stuff is easier since it can just be a scratch build from srpm and people need not push the git content back to git.centos.org till embargo expiry. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

7 14

CentOS Bug Tracker and ABRT
by Jakub Filak 04 Feb '15

04 Feb '15

Hello everyone, I want to briefly introduce myself. I am a Red Hat employee working on ABRT[1]. We have recently added support for CentOS on the ABRT server[2] and we would like continue in these integration efforts. First of all, I want to submit a pair of patches improving ABRT's UX on CentOS: - do not offer users to report to Red Hat Portal - offer users to send an email to upstream - stop wasting of resources by running sos, because its output is useless for CentOS users In the near future, we would like to integrate ABRT with CentOS Bug Tracker in the same way as ABRT integrates with Red Hat Bugzilla[3]. We are done with the analysis phase[4] and, now, we are working on a testsuite[5]. Unfortunately, MantisBT misses more advanced searching what prevents us from implementing a tool similar to one we have for Bugzilla. At least we need to search by DUPHASH (an unique identifier of a crash, something like tag). Would you be willing to run a MantisBT plugin adding the things we need, if we develop it? Best regards, Jakub http://wiki.centos.org/JakubFilak 1: https://github.com/abrt 2: https://abrt.fedoraproject.org/ 3: https://github.com/abrt/libreport/issues/272 4: https://github.com/abrt/libreport/wiki/MantisBT 5: https://github.com/abrt/abrt/tree/reporter-mantisbt

4 12

Image building features enabled in CBS
by Ian McLeod 14 Jan '15

14 Jan '15

Hello all, Thanks to Thomas' (alphacc) work last Friday, we now have the image building features enable on the CBS koji instance. I'll give a very brief summary of how to use it. The general form of the koji command is: koji -p cbs image-build <image_name> <image_version> <build_target> <install_tree_url> <arch> --release <image_release> --distro <distro_name_version> --kickstart <local_kickstart_file> --format <format_type> --disk-size <disk_size_in_gb> --repo <repo_url> (optional) --scratch (optional) --nowait (optional) The image build must be given a name, version and release. These function in much the same way as they do in RPM. In particular, the name must be added as an allowed package in the output tag for the <build_target> provided on the command line. You can specify more than one --format option. The most useful options are: 'raw-xz' - xz compressed raw file 'qcow2' - qcow2 'rhevm-ova' - A single file OVF image (aka OVA) for RHEV-M 'vsphere-ova' - An OVA for vSphere/VMWare 'docker' - A docker base image, suitable for "docker load" Any "url" or "repo" lines in your input kickstart file will be removed. The "url" line is replaced by whatever <install_tree_url> you give above. You can, optionally, provide additional repos to Anaconda by giving one or more "--repo <url>" arguments. Until we sort out how exactly we want kickstart files store in RCM (likely git.centos.org) we will be restricted to doing scratch builds, indicated with a "--scratch" option above. Here is the exact command I used to do initial testing of the feature: koji image-build \ centos-7-imcleod-test 1 atomic7-el7.centos \ http://mirror.centos.org/centos/7/os/x86_64/ x86_64 \ --release=1 \ --distro RHEL-7.0 \ --kickstart=/tmp/RHEL7.auto \ --format=qcow2 \ --scratch \ --nowait \ --disk-size=10 The "RHEL7.auto" kickstart is the minimal/JEOS RHEL7 kickstart from Oz, available here: https://raw.githubusercontent.com/clalancette/oz/master/oz/auto/RHEL7.auto In order for this to work I had to ask alphacc to add me to the "image" permission in the CBS. I then had to add the centos-7-imcleod-test "package" to the "atomic7-testing" tag (which is the destination for the "atomic7-el7.centos" build target). The command to do this was: koji add-pkg --owner=imcleod atomic7-testing centos-7-imcleod-test Please follow up with questions, thoughts, RFEs, etc. -Ian

3 3

Re: [CentOS-devel] When anyone has plan to have this patch to CentOS 6.5?
by Subscribe Ling 16 Dec '14

16 Dec '14

I have opened a bug here and hope get response ASAP. https://bugzilla.redhat.com/show_bug.cgi?id=1154747 Thank you, *Johnny!* *Paul*

3 4

RFC: OCaml SIG
by Jon Ludlam 13 Dec '14

13 Dec '14

Hi all, I'd like to propose a new SIG for the OCaml language. OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles. It has in recent years seen a marked increase in development activity, particularly in the compiler itself [1], core libraries [2] and developer tools [3]. Many of these newer libraries and features are already dependencies of a number of large upstream projects [4]. The version of OCaml in CentOS 6 is quite old (3.11.2, released in Jan 2010), and even that in CentOS 7 is fairly old (4.00.1, released in October 2012). I see the OCaml SIG providing the current stable compiler (4.02.1 at time of writing), and a selection of useful libraries and developer tools. This could then be used as a basis for other applications or SIGs to build upon - for example, it would make CentOS a good platform for building Unikernels [5] and it would be helpful in getting the Xapi Project suite of daemons [4] into one of the virtualisation/cloud SIGs. We actually already have a number of specs that are built for CentOS 6 which could make a good starting point [6]. A number of people have already agreed that they are interested and may be able to help (all CC'd): >From OCaml Labs (http://www.cl.cam.ac.uk/projects/ocamllabs/): - Anil Madhavapeddy - Thomas Gazagnaire >From Jane Street (https://www.janestreet.com/): - Yaron Minsky - Dominick LoBraico >From Citrix (https://www.citrix.com/): - Me - Euan Harris >From OCamlPro (http://www.ocamlpro.com/): - Louis Gesbert Comments? Jon [1] GADTs, record disambiguation, PPX extensions, immutable strings, etc. [2] ocaml-ctypes, Jane Street Core, the openmirage.org suite of libraries, etc. [3] opam, merlin, utop, etc. [4] https://github.com/xapi-project and http://ocsigen.org/ [5] http://queue.acm.org/detail.cfm?id=2566628 [6] https://github.com/xenserver/buildroot

7 20

A project calendar
by Karanbir Singh 11 Dec '14

11 Dec '14

Hi There is quite a lot of stuff going on and not all of it is easily visible to everyone. The way to perhaps address that is to setup a project calendar that people can sync against and look at regularly. And more win if we can have it slightly open ended, allowing people / projects / sig's to contribute events into that cal. To that extent Stephen Smoogen introduced me to Pierre-Yves Chibo who runs the fedocal effort, and they have graciously agreed to set something up for CentOS as well. Stephen I know is on this list already, I've requested Pierre to join ( he might have done so already ). Firstly looking for comments on the idea / plan - and then for options on implemention, publishing and consumption of the calendar. Regards -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc

8 11

Switching to centralized authentication for centos.org infra (aka FAS vs IPA)
by Xavier Lamien 02 Dec '14

02 Dec '14

Greetings folks, As the principal FAS upstream, I would like to help you guys out making - as much as possible - (the right?) move by having the right information. First of all, let's start by a short FAS introduction. FAS has been designed to be community oriented by providing to the community a way to operate by itself through teams management (i.e group membership/management). As a result, our web interface has to be more than just an administrative interface to manage users & groups like other does. I recommend to go read more about it at https://admin.fedoraproject.org/accounts/about before go further. While keeping the openness, we also added: 1. A plugin Interface which let you add any new feature Plugin we had developed: * asterisk (no longer in prod however the plugin still is maintain) * yubikey (some of our group requires their members to have a key to access bound hosts) * OTP 2 factor auth (in a branch) 2. A non-standard API (current master) which let registered people and/or 3rd parties (from login mechanism) to read-only from FAS. Next is, my feedback after reviewed the wiki page and previous msg: >> project URL The project is mainly active on github (fedorahosted.org has been set as backup) v2: https://github.com/fedora-infra/fas v3.0: https://github.com/fedora-infra/fas/tree/FAS_3.0 >> packages available natively in the distro We do provide rpm's for rhel (e.g. http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noa… ) FAS v3 package will be in distro as it will be no Fedora project specific. >> multi-master replication Is this our we can replicate FAS from a master image? I really didn't get that one. If someone could explain it to me, that would be great. >> kerberos support: Not supported at this time. We do think of it for a v3.xx though. But it's not in my priority list unless someone is interesting to work on it. >> LDAP support: FAS v2: no. FAS v3.2: yes however, the LDAP support will be for group and people management. We will keep the DB as FAS is not about user and group management only. >> It's more or less a "Users CMDB" and cron jobs/scripts are creating/removing/modifying users/groups locally on each managed system. Naa, we have a fas-client which actually does the job to synchronize accounts on hosts. fas-client has been cron'd as the v2 is a non-daemon tools. We do have a daemon option though that listen to fedmsg and update hosts on demand. However, we set up a push-mode into Fedora infra. >> Mainly written to discuss with the fedmsg bus, and so targetting all Fedora Applications FAS has not been written to talk to 3rd parties (as stated in introduction). fedmsg cames few years after FASv2 launch. fedmsg is for FAS just another notification mechanism. >> Written for one project It has been the case for quite a while before I started work on FAS. For the record, I maintain the RPM Fusion infra and are using FAS there as well. even though this is related to fedora project, RPM Fusion are not providing the same level of services and doesn't have the same team structure (we don't use license agreement feature, nor asterisk's one, nor bugzilla feature atm). >> but we are working on a new fas 3 version that will use flask. Naa.. FAS 3 is a pyramid app. >> I guess it would be easier for everybody too, as just for today I've read that FAS3 would be in fact based on IPA so not on the actual FAS setup Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS. If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;) - Xavier

3 3

cloud-init in CentOS
by Sam Kottler 02 Dec '14

02 Dec '14

During the cloud instance SIG meeting today we talked about future plans for cloud-init in CentOS. Right now cloud-init is included as part of EPEL and that's where most CentOS users consume it from. The problem is that cloud-init and related bits are critical for building images to run on a public or private cloud, and we need to build early guest initialization tools into the cloud images we produce. Ideally this does not include adding EPEL or packages from EPEL which have not been rebuilt in our build systems. So, the proposal that there's general consensus upon within the SIG is to maintain cloud-init, its dependencies, and any related packages on git.centos.org and rebuild them ourselves. I'm one of the maintainers in EPEL so I offered to maintain the git repos for CentOS, anyone else who would like to be involved in more than welcome to step up. Thoughts, questions, concerns? -s

7 17

Re: [CentOS-devel] [rh-scl] Proposal for CentOS dist-git design
by Honza Horak 01 Dec '14

01 Dec '14

On 11/26/2014 07:51 AM, Remi Collet wrote: > Le 25/11/2014 09:05, Honza Horak a écrit : >> Hi guys, > > Hi, > >> this is a draft for CentOS dist-git design I put together from various >> notes/ideas. It still needs to polish, so it will probably be changing >> in but I wanted to share it as soon as possible to gather feedback soon >> and incorporate your ideas. >> >> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > > First, sorry for stupid questions, but it seems I still haven't > understand the goal, what we want to fix, and how. Remi, thanks for them! For some I had no answer yet, so I added them to the wiki with some just figured out answer: https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal#FAQ Also CC'ing centos-devel list, since these are all questions we need to answer publicly. So, what we want to fix here.. CentOS is a platform used by huge amount of users, who e.g. develop apps for RHEL. Missing SCLs in CentOS is then problem for those users, because they cannot develop apps using SCLs. I guess there are no doubts SCLs are needed in CentOS. Then, why move *development of the future SCLs* to CentOS and not rebuild RHSCL there downstream? There are RH projects (like OpenShift) that also need to have community version of the product available publicly for all, so they started to use CentOS as their development platform. That means fixes land in git.centos.org first, where everybody can test, and community can see code that will land in RH in the future. So they build community on CentOS. Given there are already projects using CentOS as development platform and given users use CentOS as development platform, we see it as great opportunity to build community around SCLs there as well, which is what SCLs is missing. Also, it makes sense to have a common platform where upstream development of RH layered products takes place and where products may interact. We consider CentOS to be this platform now. > > "... where future upstream development of Software Collections > will take place" > > So, if I understand correctly, if I want to create a "php56" collection, > I should be able to do it in git.centos.org ? Yes. > Where the packages will go (which repository) ? My proposal is to use one repository on CentOS side for all collections. However, this will be a different repository than the one for rebuilt RHSCL collections (if there ever will be such a repository). > How user will see the difference between "stable" packages and > "development" packages ? I'm not sure yet, but there can be two repositories. One repository with stable downstream rebuild of RHSCL, another with SCLs that include fixes above RHSCL and have quality compared to Fedora. > If, at some time, RH provides a "php56" collection, this can be pulled > from this one. But what will happen next to earlier packages ? Nothing, it will stay, new patches will still be landing there before they land in RHSCL. > Will the ACL on the package stay the same ? ACLs were not consulted yet. > About koji setup: > > Which repository/tags will be enabled in each target ? I expect only CentOS and already built SCLs will be available. > Especially, will EPEL be available, or some replacement ? I don't think so, why EPEL? > Will the SCL-SIG be able to add additional packages in existing > collections ? If you mean already released collections, we haven't consulted what will happen with them, just that sources are already available for CentOS and we'll let CentOS community to build them. For new collections, which are subject of this proposal, it will be possible. > Exemple : for now, Fedora is upstream for RHEL, packages are then split > between RHEL and EPEL (short way to describe what happen). > > How can we manage, p.e. php-mcrypt (huge user demand) in this > configuration ? (part of php in Fedora, and php-extras in EPEL). Not sure what are you asking for. php-mcrypt will be part of php56 collection for instance, but I probably did not understand the question. >>From my point of view, there should be a clear definition of "upstream" > > Old: > "Fedora is upstream of RHEL" > New: > git.centos.org is upstream of RHSCL, > in one "experimental" repository > (not yet in RHSCL) Yes. > Old: > "RHEL is upstream of CentOS" > New: > git.centos.org receive clone copy of RH content > in one "production" repository. > (clone of RHSCL) > > git.centos.org produce more content > in one "additional" repository > (like EPEL for RHEL) Yeah, the whole point is that CentOS won't be only downstream for all RH products any longer. It will stay downstream for RHEL, but upstream for some other projects. > I think we probably even need more git or more branches, not a single one) Git will be similar to what we have internally, one repository per component and branch for every "combination of CentOS and collection" where it makes sense. But it is already mentioned in the proposal. > > Regards, > Remi. > > > > P.S. are we trying to kill Fedora ? I hope not :) Just SCLs don't bring so much value for Fedora users, since they already have their packages in latest versions there. That does not mean SCLs are not usable there, I'd love to see SCLs in Fedora still; just we focus more on CentOS now because it will solve more issues for more users currently. Honza

2 2

Proposal for a bi-weekly Storage SIG meeting
by Lalatendu Mohanty 28 Nov '14

28 Nov '14

Hi All, Lets meet at 15:00 UTC, Wednesday or Friday bi-weekly in #centos-devel for Storage SIG [1]. Does this time i.e. 15:00 UTC work for you? yes/no/suggestion? Which day works better for you? Wednesday or Friday? Agenda might be something like this: #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic:OpenAFS #info Subtopic: Ceph #info Topic: Open Floor [1] http://wiki.centos.org/SpecialInterestGroup/Storage Thanks, Lala #lalatenduM

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel November 2014