making Container Best Practices push to /docs/ work

[projectatomic]

making Container Best Practices push to /docs/ work

[jlebon]

I can create the actual automation job part easily. If there are no bots already set up, I don't mind using my OO account. I assume the server would accept just a simple scp/rsync?

Ping @baude also.

[mscherer]

For now, we use a bot to deploy (with a email alias), but I would prefer use a 2nd one for others stuff. I would also recommend against using personal account, since that's the kind of stuff causing trouble when someone leave the team/company.

[jlebon]

No problem with me. Will you create the 2nd bot account, or should I?

[mscherer]

You can create, or if you give me your email, i can add you admin on the gear (and then trust you to do the right stuff)

[jlebon]

Got it, thanks. Had a look around, but yeah I think we can figure out the automation part. The only unknown left is part (1) of this issue.

[mscherer]

So the part one should be straight forward, if we add the file, apache will serve it. The real question is how do we make middleman deploy (who use rsync) to deploy the website and not erase the files who are not part of the build, while at the same time not keeping old middleman generated files around.

A clean solution would be to have it on openshift v3, with 1 pod for the website, with 1 single container for httpd, using multiple containers for data pods. So each data would be self contained and without any risk of breaking the website, build with openshift v3 STI, and we can do proper redirection in the httpd container.

(and no, we can't use Alias in a .htaccess, as this would have solved the solution).

I would vote "live with the file not being removed until online go to v3".

[jberkus]

Well, if we're serving via Apache and not via exec, then I should just need to add an ignore to config.rb, no?

Relevant to this: Container Best Practices is the first of many docs we're going to be doing this with, so we want to come up with a solution which "scales".

[mscherer]

using ignore is likely not gonna do what you think it does.
While the doc is surprising ( https://www.relishapp.com/middleman/middleman-core/docs/ignoring-paths ), my understanding is that this is basically the equivalent of a .gitignore, and have a effect at build time. That's not something we need, we are using a VCS so we can just delete the file :)

What you are likely looking for is this:
https://github.com/projectatomic/atomic-site/blob/master/config.rb#L287

this is the setting that make middleman deploy remove or not distant file he do not know. Since the idea is to push from difference source, it make sense to turn that off, with the side effect of not being able to clean ( as I said in my previous comment). So we have to decide if that's a acceptable tradeoff or not (especially since we can always clean manually if needed).

[jberkus]

Is that strictly global, or can we set "clean" on a per-directory basis? That's why I was looking at "ignore".

Having clean=false affect /source/blog would be a pain, we often rename the blog filenames.

[mscherer]

That's global.

Do we rename the file after being pushed/published ? because then we should set proper redirect somewhere, since it would therwise 404 and I do not see any redirects in the code.

[jberkus]

Oh, point, we don't.

[bexelbie]

Could we just create docs.projectatomic.io? This would probably help if we add more docs in the future ...

[jzb]

That does seem like a reasonable solution.

[jberkus]

Note that we already have a request to publish a 2nd repo, for Atomic Registry.

I'm fine with docs.projectatomic.io; what will it take to launch that?

[mscherer]

Decide the hosting (ie, is openshift online ok), then we modify the dns to point to the instance, then someone do the magic various rsync to push.

[bexelbie]

If we stick with openshift, we can do a rebuild via webhook as everything is upstream

[mscherer]

Can you explain a bit more how it would work with openshift v2, as that's a part I never used; Also, does it work fine with multiple git repo mapped to 1 single gear, because that's also one of the limitation that made me do my own middleman build script.

[bexelbie]

@mscherer I cannot, however I believe the folks I share an office with can. They aren't on my team, so I'll bug them when I get back into the office (post snow-pocoalypse)

[mscherer]

So the idea is to get a 2nd gear for the docs, and let it be just a regular httpd one without specific application ? It would work too, and be simpler.

[baude]

That sounds good @mscherer and @jberkus . Can we get this in motion?

[mscherer]

So I created the gears:

Connect using 56e1f0332d5271c26d0000b8 on docs-atomicproject.rhcloud.com, from any of the current admins (ie, everybody in this thread, except people whose first name start by a B, sorry)

Just upload the file on app-root/repo/diy/ , erase the current index.html and it should be ok (I think)

@jlebon , you likely have access, can you take care of the automation, I will add the domain once we are sure everything is working.

[jlebon]

@baude So is it just make html and then index.html is the only artifact we need to upload?

[baude]

and the images dir. ill tickle you on irc.

[jlebon]

@baude The automation job is currently under review. In the meantime, here's what it looks like from my test pushes: http://docs-atomicproject.rhcloud.com/container-best-practices/

Looks like the sidebar isn't being rendered properly.

[baude]

yeah, unfortunately that is the way the style looks for now. can you try 'make plain-html' ?

[jlebon]

OK, the job is installed. Commits should normally trigger an update within the minute.
I changed it to plain-html as well for now, which looks much nicer.

@baude If there's nothing left to do on the build side, I think @mscherer can create the domain.

[baude]

imho, we can work the style issues out and leave it as plain-html for now! thanks so much folks.

[mscherer]

That's live:

http://docs.projectatomic.io/container-best-practices/

Someone still need to edit the root of the website however.

[jlebon]

I updated the root to at least not show the default OpenShift v2 page. I suppose eventually we'll need a nice landing page there with a list of the hosted documentation.

[jberkus]

I'd like a designer to do the root. Lemme bug @tigert using another issue.

[bexelbie]

@mscherer @jlebon where are the automation scripts/tasks/builders that build docs.projectatomic.io living? I want to work with @Preeticp on getting ADB, vagrant-service-manager, adb-utils, atomic app and nulecule buliding for this site too.

[mscherer]

I have no idea on my side. But we are starting to get a sizable infra (ie, more than just "builder + website", so maybe we could start to document that somewhere ?

[jlebon]

@bexelbie The builder is running on the internal Jenkins for now. If it's easy to build those docs (using docker hopefully? :)), then I can simply add them. Maybe in a different issue?

[bexelbie]

@jlebon @mscherer Any docs that can land in the public space that describe building the site is useful.

[jberkus]

Moved to https://github.com/projectatomic/docs.projectatomic.io/issues/3