Re: [cloud] #123: Document process for using Fedora-Dockerfile branches

[Fedora Cloud Trac Tickets]

#123: Document process for using Fedora-Dockerfile branches
--+-
 Reporter:  scollier  |   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Future
Component:  ---   |  Resolution:
 Keywords:  meeting   |
--+-

Comment (by adimania):

 Replying to [comment:3 bkabrda]:
 > Hi, I'd suggest creating a CONTRIBUTING.md file and putting the
 contribution guidelines in there. This way, Github will show it as a link
 in all pull requests. Perhaps you could create a pull request that would
 add this file and we could discuss the guidelines there?
 Sounds good. Let us discuss with others and close this in the meeting.
 >
 > As for the part you created, I think it looks good overall, I just have
 some minor comments:
 > * "It is done to ensure that we do not break the package in different
 releases of Fedora" - what do you mean by "break the package"? Which
 package is that?
 fedora-dockerfiles package is built for fedora repos and for epel.

 > * "We would test the Dockerfile against right the Fedora release"
 >   * Did you mean to write "against the right Fedora release"?
 Yes. I have corrected this.
 >   * If so, what exactly does that mean? What is the right Fedora release
 to test an image against?
 An image which comes to f22 branch should be tested against fedora 22
 release.
 >
 > If you do decide to create a pull request as I suggested above, I also
 have several more suggestions:
 > * Remove the section "The version of Docker that it was created and
 tested on."; it's not really important and it makes the READMEs look
 obsolete.
 I am not sure about this. If we had CI, I could let go of it. Without CI,
 I am not really sure.
 > * Remove the section "Instructions on how to build the Docker image.".
 Building instructions are pretty much the same for all the images and I
 don't think it's necessary to have them in all READMEs. Let's just have
 one instruction in the top level README file like "you can build any of
 the images as 'docker build --rm -t fedora/ .'"
 This sounds good. I will go through some of the Dockerfiles and will make
 the suggested changes if I don't see any anomaly.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Becoming comaintainer for Fedora-Dockerfiles

[Dusty Mabe]

On 10/06/2015 10:13 AM, Matthew Miller wrote:

On Fri, Oct 02, 2015 at 05:01:51AM -0400, Bohuslav Kabrda wrote:

Heh, it seems that my career as Fedora-Dockerfiles comaintainer may
be rather short :) I think having a web frontend with pull requests
for the new dist-git is an awesome idea. I'm +0.9 for pagure. The
advantage is that it will be completely under Fedora control, the
small downside is that potential contributors from outside Fedora
will have to create Fedora account, which might scare some people
off.

We want to make the web-pull-request process really easy for using
Pagure as a documentation tool, too, so support for
non-fedora-contributor drive-by contributions might come.


I really think a 'log in with github' ability would be great for pagure. 
It would also be great to have for BZ (which I know isn't FAS) but would 
make it easier for people who didn't want to create an account but 
wanted to report a bug.

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Becoming comaintainer for Fedora-Dockerfiles

[Adam Miller]

On Tue, Oct 6, 2015 at 11:21 PM, Bohuslav Kabrda  wrote:
> - Original Message -
>> On Fri, Oct 2, 2015 at 4:01 AM, Bohuslav Kabrda  wrote:
>> > - Original Message -
>> >> On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
>> >> > >My opinion is that the dist-git-for-dockerfiles plan should make Fedora
>> >> > >Dockerfiles obsolete.
>> >> > How would users who aren't necessarily involved in the Fedora build
>> >> > process experiment building images with a Fedora base?  Right now
>> >>
>> >> Hopefully this new dist-git can be fronted by pagure, so it'd be a
>> >> matter of visiting a web site like https://pagure.io/fedora-bootstrap
>> >> (not a docker example, just a random one) and either downloading the
>> >> docker file or doing a git clone.
>> >
>> > Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be
>> > rather short :)
>> > I think having a web frontend with pull requests for the new dist-git is an
>> > awesome idea. I'm +0.9 for pagure. The advantage is that it will be
>> > completely under Fedora control, the small downside is that potential
>> > contributors from outside Fedora will have to create Fedora account, which
>> > might scare some people off.
>>
>> From what I understand is that pagure uses OAuth and at the moment the
>> only OAuth plugin in use is for FAS, we might be able to request to
>> enable some short list of federated logins if:
>> 1) that is in fact possible
>> 2) the authors of pagure are open to it
>> 3) the Fedora Infrastructure team is OK with it
>
> That would be nice! I'll try to ask pingou whether this would make sense to 
> him (hopefully in the start of next week, I'm going to a conference for the 
> rest of this week).

+1 - Sounds good.

>
>> >> > there's a rpm created from fedora-dockerfiles that includes all the
>> >> > Dockerfiles and makes it easy to experiment by placing all the
>> >> > Dockerfiles in /usr/share/fedora-dockerfiles.  If we keep them both,
>> >> > it's somewhat duplicate work.  I'm just curious how it would look.
>> >> > Right now the barrier to entry for experimentation is low. I'm
>> >> > concerned about raising that.
>> >>
>> >> Yeah, that's a good concern. We could also perhaps automate pulling all
>> >> the dockerfiles from the dist-git into fedora-dockerfiles and keep
>> >> that, for people who want to work with it that way.
>> >
>> > So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg
>> > clone mariadb-docker" or similar. Perhaps we could provide a wrapper that
>> > anyone, even without Fedora account, like "fedora-get-dockerfile --list"
>> > or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone
>> > --anonymous mariadb-docker").
>>
>> Ultimately people could just git clone from the git repo in pagure.
>
> Yeah, you're right.
>
>> The only real thing that makes DistGit "special" is the branch layout,
>> relationship, and some git hooks. Otherwise it's still just git and we
>> can aggregate that information any way we choose. If there's
>> ultimately a desire for a web hub, it's possible we could get
>> something together similar to Fedora Packages[0]
>>
>> >
>> >> > Also, the plan was for Vasek to submit Nulecule PRs to
>> >> > Fedora-dockerfiles, at some point, so people could experiment with
>> >> > them as well.  I'd also like to see k8s example json / yaml files
>> >> > associated with select fedora-dockerfiles for easy experimentation.
>> >> > Would the nulecule / k8s get pushed into the dist-git as well?
>> >>
>> >> Maybe? Would it make sense for these to go together with the
>> >> dockerfiles they're associated with in a git repo at that level, or
>> >> would they be stand-alone and reference other repos? (Do you have some
>> >> concrete examples?)
>> >
>> > So I think that kubernetes/Nulecule examples should be standalone, since
>> > most often they'll reference multiple images. What I mean is that they
>> > would be a good fit for the current fedora-dockerfiles repo, but if we
>> > split the repo into multiple dist-git repos, they won't fit in any one of
>> > these.
>>
>> I'm not sure that I follow the motivation behind keeping them
>> standalone, could you elaborate why? Also, when you say "reference
>> multiple images" so you mean as a Nulecule spec or $other/$similar?
>
> So *assuming* we split fedora-dockerfiles in one-dockerfile-per-dist-git-repo 
> style and there's a kubernetes/Nulecule file that references (*) more of 
> them, it just doesn't fit into any one of these one-dockerfile repos.
>
> (*) It's pretty much as you said it, an application based on e.g. a 
> kubernetes config file will *typically* operate with (and thus reference) 
> more than just one image.

Yes, I agree. For things like kubernetes and/or nulecule application
definitions, I think those should live somewhere external
independently at least for now. This isn't something we've currently
been planning to handle in the Layered Image 

Cloud Meeting Minutes 2015-10-07

[Dusty Mabe]

html version: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.2015-10-07-17.02.html
text version: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.2015-10-07-17.02.txt

=
#fedora-meeting-1 Meeting
=


Meeting started by dustymabe at 17:02:30 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-07/cloud_wg.2015-10-07-17.02.log.html
.



Meeting summary
---
* rollcall  (dustymabe, 17:02:42)
  * LINK:

https://meetbot.fedoraproject.org/sresults/?group_id=fedora-meeting-1=team
(dustymabe, 17:06:50)
  * LINK:

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-23/cloud_wg.2015-09-23-17.00.txt
(roshi, 17:08:17)

* last meeting items  (dustymabe, 17:09:21)
  * LINK: https://fedorahosted.org/cloud/ticket/94   (dustymabe,
17:10:11)
  * LINK: https://fedoraproject.org/wiki/Cloud/Network-Requirements
(maxamillion, 17:10:42)
  * LINK: https://fedoraproject.org/wiki/Cloud/Network-Requirements
(dustymabe, 17:11:29)
  * maxamillion spoke with mhayden and he updated the wiki page
(dustymabe, 17:11:40)

* Migrate all Dockerfiles / Images to systemd where possible
  (dustymabe, 17:13:48)
  * LINK: https://fedorahosted.org/cloud/ticket/121   (dustymabe,
17:13:57)

* Migrate all Dockerfiles / Images to systemd where possible
  (dustymabe, 17:17:51)
  * LINK: https://fedorahosted.org/cloud/ticket/121   (dustymabe,
17:17:59)

* fedora-dockerfiles: Clean up READMEs.  (dustymabe, 17:18:25)
  * LINK: https://fedorahosted.org/cloud/ticket/122   (dustymabe,
17:18:34)

* Document process for using Fedora-Dockerfile branches  (dustymabe,
  17:21:24)
  * LINK: https://fedorahosted.org/cloud/ticket/123   (dustymabe,
17:21:30)

* CI for Fedora-Dockerfiles  (dustymabe, 17:24:07)
  * LINK: https://fedorahosted.org/cloud/ticket/124   (dustymabe,
17:24:15)

* Fedora-Dockerfiles examples for Kubernetes  (dustymabe, 17:29:45)
  * LINK: https://fedorahosted.org/cloud/ticket/125   (dustymabe,
17:29:53)

* open floor  (dustymabe, 17:32:42)
  * LINK: https://apps.fedoraproject.org/autocloud/jobs/ is finally on
production  (kushal, 17:33:05)
  * ACTION: dustymabe to create ticket to figure out python3/ansible
requirements for cloud  (dustymabe, 17:40:45)

Meeting ended at 17:45:53 UTC.




Action Items

* dustymabe to create ticket to figure out python3/ansible requirements
  for cloud




Action Items, by person
---
* dustymabe
  * dustymabe to create ticket to figure out python3/ansible
requirements for cloud
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (108)
* roshi (30)
* kushal (20)
* adimania (20)
* maxamillion (17)
* zodbot (12)
* jbrooks (6)
* number80 (2)
* gholms (2)
* rtnpro (2)
* smdeep (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct