#3860 Test box for Publican 3
Closed: Fixed None Opened 10 years ago by sparks.

The Docs Project needs a test system setup for our docs.fp.o replacement. It needs to be on a EL 6 box with the optional channel activated.


Does it need to be accessible in any special way? Could it just be a private cloud instance?

Just need a few more pieces of info to fulfill your request

Replying to [comment:1 skvidal]:

Does it need to be accessible in any special way? Could it just be a private cloud instance?

That should be fine.

So after irc discussions last night I am trying to figure the best way to handle things. :)

Some more questions:

  • Currently we pull from the docs git repo every hour and sync that to our proxies. Under this new setup, changes would be committed to git, then a koji build would be run, then we would need to sign/compose that build into a repo and update the rpms. I can't see this happening every hour. What is the desired update frequency on the produced docs packages?

  • I have 0 desire to install publican and it's dep stack on all our proxy servers. Is there any way to take the content in the new git repo and build the static files needed in one place and sync that out as content instead of rpms? Building rpms in koji could be still done and fine, we just don't need to use them ourselves.

  • If there's no way to do what was in the last point, is there any way one of the rpm subpackages could be the full content without requiring publican?

  • Mention was made that publican3 is required and that you would want to stay pretty bleeding edge on publican. Where is this el6 publican3 package? Who maintains it?

Replying to [comment:3 kevin]:

  • Currently we pull from the docs git repo every hour and sync that to our proxies. Under this new setup, changes would be committed to git, then a koji build would be run, then we would need to sign/compose that build into a repo and update the rpms. I can't see this happening every hour. What is the desired update frequency on the produced docs packages?

I think there is confusion here. What we would publish would be rolled into an SRPM for koji and would not need to go to a git repo. The web instance on the backend should be installing those packages that koji built to then be sent to the proxies.

  • I have 0 desire to install publican and it's dep stack on all our proxy servers. Is there any way to take the content in the new git repo and build the static files needed in one place and sync that out as content instead of rpms? Building rpms in koji could be still done and fine, we just don't need to use them ourselves.

You shouldn't have to install publican on the proxy servers. The SRPMs contain all the HTML data (and PDFs and ePubs) that goes to the backend server.

  • If there's no way to do what was in the last point, is there any way one of the rpm subpackages could be the full content without requiring publican?

Unless the process has been completely misrepresented to me there isn't a need to install publican on the backend. If I'm mistaken I wish someone would draw me a picture because I just don't see it.

  • Mention was made that publican3 is required and that you would want to stay pretty bleeding edge on publican. Where is this el6 publican3 package? Who maintains it?

I no longer have a RHEL box to play with but I know that P3 was built for CSB. The builds exist somewhere if not already in EPEL.

ok, we hashed this out some more on irc, and the way forward:

  • We need a publican3 build in EPEL (or at least a src.rpm we can build and put in our infra repo for now). We want to get publican3 in EPEL tho so it's supported/has bug tracking/official builds, etc.

  • I'm going to stand up a docs-backend01 el6 instance. Install publican on it from above.

  • Next we need to build docs in koji and script docs-backend01 in hourly updating them. (yum-cron will do this)

  • Once those look good, we can change our proxies to sync from docs-backend01 for the content.

All reasonable?

Current version of publican is a bit newer, but jfearn had some RPMS and SRPMS available here of 3.0.0 which somebody could use as a starting point. (Haven't looked at how different it is to current Fedora spec, just had this bookmarked from a while ago.)

http://jfearn.fedorapeople.org/rpms/publican-3.0.0-el6/

Replying to [comment:3 kevin]:

So after irc discussions last night I am trying to figure the best way to handle things. :)

Some more questions:

  • Currently we pull from the docs git repo every hour and sync that to our proxies. Under this new setup, changes would be committed to git, then a koji build would be run, then we would need to sign/compose that build into a repo and update the rpms. I can't see this happening every hour. What is the desired update frequency on the produced docs packages?

  • I have 0 desire to install publican and it's dep stack on all our proxy servers. Is there any way to take the content in the new git repo and build the static files needed in one place and sync that out as content instead of rpms? Building rpms in koji could be still done and fine, we just don't need to use them ourselves.

Exactly! :)

  1. Docs uses Koji to build the docs RPMs
  2. A staging server installs those RPMs and generates the static website (this lives under /var/www/html/docs) (the machine requested in this ticket is a test box for exactly such a stage; if the test works as expected, the machine requested here could even be repurposed as the production stage)
  3. the contents of the stage's /var/www/html/docs directory get synced out to the rest of the world
  • If there's no way to do what was in the last point, is there any way one of the rpm subpackages could be the full content without requiring publican?

  • Mention was made that publican3 is required and that you would want to stay pretty bleeding edge on publican. Where is this el6 publican3 package? Who maintains it?

Current (3.1) spec and tarball are here: https://fedorahosted.org/releases/p/u/publican/

I've uploaded builds of publican itself and its web content subpackage (publican-common-web) to http://rlandmann.fedorapeople.org/publican-3.1/

I maintain Publican in Fedora; I'm happy to maintain the el6-docs version of it too. (and also happy for comaintainers).

Cheers

Rudi

Replying to [comment:4 sparks]:

Replying to [comment:3 kevin]:

  • Currently we pull from the docs git repo every hour and sync that to our proxies. Under this new setup, changes would be committed to git, then a koji build would be run, then we would need to sign/compose that build into a repo and update the rpms. I can't see this happening every hour. What is the desired update frequency on the produced docs packages?

I think there is confusion here. What we would publish would be rolled into an SRPM for koji and would not need to go to a git repo. The web instance on the backend should be installing those packages that koji built to then be sent to the proxies.

Correct

  • I have 0 desire to install publican and it's dep stack on all our proxy servers. Is there any way to take the content in the new git repo and build the static files needed in one place and sync that out as content instead of rpms? Building rpms in koji could be still done and fine, we just don't need to use them ourselves.

You shouldn't have to install publican on the proxy servers. The SRPMs contain all the HTML data (and PDFs and ePubs) that goes to the backend server.

Correct

  • If there's no way to do what was in the last point, is there any way one of the rpm subpackages could be the full content without requiring publican?

Unless the process has been completely misrepresented to me there isn't a need to install publican on the backend. If I'm mistaken I wish someone would draw me a picture because I just don't see it.

Almost correct. The backend server (the "staging server", ie, this box) does need to run Publican, because Publican (running on the back end) automatically generates and updates the site navigation pages. (For those of us like Sparks who have built a site manually with Publican, this is what happens during the "publican install_book" action; Publican is triggered to do this in %post. Conversely, it runs its remove_book action by %postun)

  • Mention was made that publican3 is required and that you would want to stay pretty bleeding edge on publican. Where is this el6 publican3 package? Who maintains it?

I no longer have a RHEL box to play with but I know that P3 was built for CSB. The builds exist somewhere if not already in EPEL.

Unfortunately, not in EPEL6 and never can be; we have perl deps that are newer than what's shipped in RHEL6. This is why I've requested (and now mostly have...) a separate buildroot for Publican 3 (this is el6-docs in Koji) -- https://fedorahosted.org/rel-eng/ticket/5214 -- as soon as rel-eng turns on SRPM builds there, that part is done.

Cheers,
Rudi

Replying to [comment:5 kevin]:

ok, we hashed this out some more on irc, and the way forward:

  • We need a publican3 build in EPEL (or at least a src.rpm we can build and put in our infra repo for now). We want to get publican3 in EPEL tho so it's supported/has bug tracking/official builds, etc.

I'm happy to be responsible for this support, bug tracking, and builds in the el6-docs branch.

  • I'm going to stand up a docs-backend01 el6 instance. Install publican on it from above.

Thanks; please let me know if I can be of any help! :)

  • Next we need to build docs in koji and script docs-backend01 in hourly updating them. (yum-cron will do this)

  • Once those look good, we can change our proxies to sync from docs-backend01 for the content.

Perfect! :D

ok, how can we best report bugs and such against the el6-docs version of publican? publican trac?
Are there any more folks than you maintaining it currently? Would be nice to at least get one other person up to speed in case you are not available.

I have created a docs-backend01 instance now, need to get publican installed on it and move on from there. Perhaps next week we could meet up on irc to work on any last details?

Replying to [comment:10 kevin]:

ok, how can we best report bugs and such against the el6-docs version of publican? publican trac?

Publican's upstream has its own Bugzilla product and component; but for issues specific to the build we're using in this infrastructure, I've just opened a request for a component in the Fedora Documentation product: https://bugzilla.redhat.com/show_bug.cgi?id=1003143

Are there any more folks than you maintaining it currently? Would be nice to at least get one other person up to speed in case you are not available.

I agree. I can pretty much guarantee at least one co-maintainer from inside Red Hat, but it would be great to have some broader community involvement too. I'll ask on docs-list.

I have created a docs-backend01 instance now, need to get publican installed on it and move on from there. Perhaps next week we could meet up on irc to work on any last details?

Absolutely! Is any day particularly good or bad for you?

Cheers
Rudi

Replying to [comment:10 kevin]:

ok, how can we best report bugs and such against the el6-docs version of publican? publican trac?
Are there any more folks than you maintaining it currently? Would be nice to at least get one other person up to speed in case you are not available.

Hi, Kevin. I'm Zac Dover, and I work in the same department as rlandmann. I have been involved in the documentation of Red Hat Enterprise Virtualization since June of 2011 (it's my day job) and I have been involved with the Publican project for the past few releases. I have worked quite a lot with rlandmann on the most recent Publican release, and I offer my services to you in the event that rlandmann should be unavailable. I'm available as backup, in the event that rlandmann should be struck by a meteor. Please let me know if I can help.

Zac

Thanks Zac! much appreciated.

ok, docs-backend01 is all setup and running.

I think this ticket is done. We can setup a new one for any further needs moving forward.

Login to comment on this ticket.

Metadata