Fedocal to prod?

[Pierre-Yves Chibon]

Hi all,

I am getting some pressure to move fedocal to production (which is
pretty nice).

So just to be sure the next steps should be:
- roll out the 0.1.0 release
- package it
  - it now has a setup.py so I hope that it'll be pretty simple
- request for hosting/hw ?
- create the adequate puppet module
  - which url? admin.fedoraproject.org/calendar ?

Do I miss anything?

Also, what's the traditional time-line to move from stg to prod?

Thanks,
Pierre

[Kevin Fenzi]

On Tue, 12 Feb 2013 19:42:56 +0100
Pierre-Yves Chibon  wrote:
> Hi all,
>
> I am getting some pressure to move fedocal to production (which is
> pretty nice).
>
> So just to be sure the next steps should be:
> roll out the 0.1.0 release
> package it
> it now has a setup.py so I hope that it'll be pretty simple
> request for hosting/hw ?
> create the adequate puppet module
> which url? admin.fedoraproject.org/calendar ?

Sounds reasonable. In addition:

- What are the monitoring requirements?

- Should we use caching/proxies for it?

- If it gets a lot of load, can we add more instances and load balance
  them?

- Whats the db requirement?
> Do I miss anything?

I think admin.fedoraproject.org/calendar or perhaps
apps.fedoraproject.org/calendar would be fine.
> Also, what's the traditional time-line to move from stg to prod?

Mostly stg is so we can get puppet sorted out and find any issues with
proxying and caching and such. It can sometimes be pretty short if
there's no particular issues found.

kevin

[Pierre-Yves Chibon]

On Tue, 2013-02-12 at 13:00 -0700, Kevin Fenzi wrote:
> On Tue, 12 Feb 2013 19:42:56 +0100
> Pierre-Yves Chibon  wrote:
> > Hi all,
> >
> > I am getting some pressure to move fedocal to production (which is
> > pretty nice).
> >
> > So just to be sure the next steps should be:
> > roll out the 0.1.0 release
> > package it
> > it now has a setup.py so I hope that it'll be pretty simple
> > request for hosting/hw ?
> > create the adequate puppet module
> > which url? admin.fedoraproject.org/calendar ?
>
> Sounds reasonable. In addition:
> What are the monitoring requirements?

None specific, the standard package?
> Should we use caching/proxies for it?

Caching might be nice, especially for the ical feed if lot of people
subscribe to it/them.
> If it gets a lot of load, can we add more instances and load balance
> them?

Toshio said that should work for flask. I did not perform any tests
though.
> Whats the db requirement?

Postgres is fine.
> > Do I miss anything?
>
> I think admin.fedoraproject.org/calendar or perhaps
> apps.fedoraproject.org/calendar would be fine.

hm, since it needs login shouldn't it be admin?
> > Also, what's the traditional time-line to move from stg to prod?
>
> Mostly stg is so we can get puppet sorted out and find any issues with
> proxying and caching and such. It can sometimes be pretty short if
> there's no particular issues found.

Cool! :)

Thanks for the feedback,

Pierre

[Ralph Bean]

On Tue, Feb 12, 2013 at 09:15:42PM +0100, Pierre-Yves Chibon wrote:
> On Tue, 2013-02-12 at 13:00 -0700, Kevin Fenzi wrote:
> > On Tue, 12 Feb 2013 19:42:56 +0100
> > Pierre-Yves Chibon  wrote:
> > > Hi all,
> > >
> > > I am getting some pressure to move fedocal to production (which is
> > > pretty nice).

Good!  :)
> > I think admin.fedoraproject.org/calendar or perhaps
> > apps.fedoraproject.org/calendar would be fine.
>
> hm, since it needs login shouldn't it be admin?

I'm not sure what the original reason for the distinction was, but fyi
apps.fedoraproject.org/tagger requires login.

If it's just an aesthetic choice, I prefer the apps.fp.o/calendar one.
Either way, I can add this to the apps.fp.o/ landing page when its
ready.

-Ralph

[Kevin Fenzi]

On Tue, 12 Feb 2013 18:34:31 -0500
Ralph Bean  wrote:
> > > I think admin.fedoraproject.org/calendar or perhaps
> > > apps.fedoraproject.org/calendar would be fine.
> >
> > hm, since it needs login shouldn't it be admin?
>
> I'm not sure what the original reason for the distinction was, but fyi
> apps.fedoraproject.org/tagger requires login.

Originally, admin.fedoraproject.org was setup as https only and
applications under there could share cookies, so you could login to
say bodhi and get automatically logged into pkgdb.

When we reorganized things a while back the thought was that
'admin.fedoraproject.org' confuses people because it looks like some
kind of administrative site, not an end user facing application.

So, we have been moving to move applications to
'apps.fedoraproject.org'.
> If it's just an aesthetic choice, I prefer the apps.fp.o/calendar one.
> Either way, I can add this to the apps.fp.o/ landing page when its
> ready.

Cool.

kevin

[Pierre-Yves Chibon]

On Tue, Feb 12, 2013 at 01:00:59PM -0700, Kevin Fenzi wrote:
> On Tue, 12 Feb 2013 19:42:56 +0100
> Pierre-Yves Chibon  wrote:
> > Hi all,
> >
> > I am getting some pressure to move fedocal to production (which is
> > pretty nice).
> >
> > So just to be sure the next steps should be:
> > roll out the 0.1.0 release
> > package it
> > it now has a setup.py so I hope that it'll be pretty simple

Ok the part above is done, review is up at:
https://bugzilla.redhat.com/show_bug.cgi?id
> > request for hosting/hw ?

I will get started on this
> > create the adequate puppet module

Puppet or ansible? Which basically raise the question, what more do we need to
start moving apps to Ansible?
I kinda think it would make sense for new apps to be deployed via ansible rather
than puppet since we want to switch anyway, but that of course rely on what is
needed still :)

Pierre

[Kevin Fenzi]

On Sun, 24 Feb 2013 17:13:40 +0100
Pierre-Yves Chibon  wrote:
> On Tue, Feb 12, 2013 at 01:00:59PM -0700, Kevin Fenzi wrote:
> > On Tue, 12 Feb 2013 19:42:56 +0100
> > Pierre-Yves Chibon  wrote:
> > > Hi all,
> > >
> > > I am getting some pressure to move fedocal to production (which is
> > > pretty nice).
> > >
> > > So just to be sure the next steps should be:
> > > roll out the 0.1.0 release
> > > package it
> > > it now has a setup.py so I hope that it'll be pretty simple
>
> Ok the part above is done, review is up at:
> https://bugzilla.redhat.com/show_bug.cgi?id

You mean: 
https://bugzilla.redhat.com/show_bug.cgi?id=915074
:)

...snip...
> Puppet or ansible? Which basically raise the question, what more do
> we need to start moving apps to Ansible?
> I kinda think it would make sense for new apps to be deployed via
> ansible rather than puppet since we want to switch anyway, but that
> of course rely on what is needed still :)

Sure, we still need a few things:

1) Need to figure out at least a good starting point for organizing
things. We can always adjust, but I'd like to think about our common
uses like staging and come up with something to start with that can
work.

2) We need periodic cron jobs setup. Possibly we have it fire only when
there are changes in the repo + some wait time.

3) convert the sane parts of global and other 'base' stuff we do on all
machines to ansible from puppet. I think we can drop a bunch of useless
stuff, and also adjust our kickstarts to just install all the stuff we
want so we don't need to adjust packages and such.

4) To be paranoid (this applies mostly to migrating hosts from puppet)
I would like to: 
a) convert a host to ansible. 
b) run both puppet/ansible in turn on it and make sure things don't
flip/flop. 
c) re-install fresh and run ansible, then run puppet and make sure it
doesn't do anything that we want/need.

That way we can make sure changes are sane.

I think 1-3 are what we need before new hosts in ansbile. 4 is needed
after that after we start converting things over.

kevin