FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 07-18-2010, 04:28 AM
Mike McGrath
 
Default dev.fedoraproject.org

So it is probably time to have a dev.fedoraproject.org. Why? Well,
toshio had mentioned having others do some of the 'sysadminy' tasks so
developers can focus on development.

Also Luke had an analogous request wrt community and staging but before I
go setting things up some topics for discussion:

1) Security staging and production are identical. Since production data
regularly gets migrated to staging people that have access to one, might
as well have access to the other. Generally our staging environment is
mostly used for integration work, some load work as well.

2) Should we run development from rpms that get edited (like live patches)
or should we run them from scm(ish) checkouts. I generally vote for the
latter as it feels more useful in a development lifecycle. But we should
come up with a quick standard for how to store this stuff. something like
/srv/dev/

3) I don't want this to be all fancy. All of our apps run in their own
namespaces so we should be able to get by with one or two app dev servers
and we should be able to use them without a reverse proxy.

Questions comments? It'd be nice to just throw them all together on a
couple of hosts in their own namespace. It'll help find issues with them
playing together.

-Mike

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 07-18-2010, 12:34 PM
Xavier Lamien
 
Default dev.fedoraproject.org

On Sun, Jul 18, 2010 at 6:28 AM, Mike McGrath <mmcgrath@redhat.com> wrote:
> So it is probably time to have a dev.fedoraproject.org. *Why? *Well,
> toshio had mentioned having others do some of the 'sysadminy' tasks so
> developers can focus on development.
>
> Also Luke had an analogous request wrt community and staging but before I
> go setting things up some topics for discussion:
>
> 1) Security staging and production are identical. *Since production data
> regularly gets migrated to staging people that have access to one, might
> as well have access to the other. *Generally our staging environment is
> mostly used for integration work, some load work as well.
>
> 2) Should we run development from rpms that get edited (like live patches)
> or should we run them from scm(ish) checkouts. *I generally vote for the
> latter as it feels more useful in a development lifecycle. *But we should

+1 for scm chekouts
also save time that way.

> come up with a quick standard for how to store this stuff. *something like
> /srv/dev/

yeah, fine for me.

>
> 3) I don't want this to be all fancy. *All of our apps run in their own
> namespaces so we should be able to get by with one or two app dev servers
> and we should be able to use them without a reverse proxy.
>
> Questions comments? *It'd be nice to just throw them all together on a
> couple of hosts in their own namespace. *It'll help find issues with them
> playing together.

Well we could use them with something like "dev.fp.o/myapp" "dev.fp.o/myapp2"
Just like we're doing for admin.fp.o

Also have a subdomain dev is great. Maybe a home page would be good as well,
just my two cents.



--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 07-18-2010, 04:54 PM
Mike McGrath
 
Default dev.fedoraproject.org

On Sun, 18 Jul 2010, Xavier Lamien wrote:

> On Sun, Jul 18, 2010 at 6:28 AM, Mike McGrath <mmcgrath@redhat.com> wrote:
> > So it is probably time to have a dev.fedoraproject.org. *Why? *Well,
> > toshio had mentioned having others do some of the 'sysadminy' tasks so
> > developers can focus on development.
> >
> > Also Luke had an analogous request wrt community and staging but before I
> > go setting things up some topics for discussion:
> >
> > 1) Security staging and production are identical. *Since production data
> > regularly gets migrated to staging people that have access to one, might
> > as well have access to the other. *Generally our staging environment is
> > mostly used for integration work, some load work as well.
> >
> > 2) Should we run development from rpms that get edited (like live patches)
> > or should we run them from scm(ish) checkouts. *I generally vote for the
> > latter as it feels more useful in a development lifecycle. *But we should
>
> +1 for scm chekouts
> also save time that way.
>
> > come up with a quick standard for how to store this stuff. *something like
> > /srv/dev/
>
> yeah, fine for me.
>
> >
> > 3) I don't want this to be all fancy. *All of our apps run in their own
> > namespaces so we should be able to get by with one or two app dev servers
> > and we should be able to use them without a reverse proxy.
> >
> > Questions comments? *It'd be nice to just throw them all together on a
> > couple of hosts in their own namespace. *It'll help find issues with them
> > playing together.
>
> Well we could use them with something like "dev.fp.o/myapp" "dev.fp.o/myapp2"
> Just like we're doing for admin.fp.o
>
> Also have a subdomain dev is great. Maybe a home page would be good as well,
> just my two cents.
>

My only concern there is with having multiple dev app servers. We won't
have a reverse proxy for them so I was thinking something more like:

http://app01.dev.fedoraproject.org/ and
http://app02.dev.fedoraproject.org/. It lets people know it's a dev box
but also allows say, luke to be doing really crazy drastic stuff on app1
and toshio to do really crazy drastic stuff on app2 without having to
worry about stepping on eachothers toes. I guess I'm hoping for a fairly
dynamic workflow on the dev servers.

-Mike______________________________________________ _
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 07-18-2010, 07:28 PM
Stephen John Smoogen
 
Default dev.fedoraproject.org

On Sat, Jul 17, 2010 at 22:28, Mike McGrath <mmcgrath@redhat.com> wrote:
> So it is probably time to have a dev.fedoraproject.org. *Why? *Well,
> toshio had mentioned having others do some of the 'sysadminy' tasks so
> developers can focus on development.
>
> Also Luke had an analogous request wrt community and staging but before I
> go setting things up some topics for discussion:
>
> 1) Security staging and production are identical. *Since production data
> regularly gets migrated to staging people that have access to one, might
> as well have access to the other. *Generally our staging environment is
> mostly used for integration work, some load work as well.
>
> 2) Should we run development from rpms that get edited (like live patches)
> or should we run them from scm(ish) checkouts. *I generally vote for the
> latter as it feels more useful in a development lifecycle. *But we should
> come up with a quick standard for how to store this stuff. *something like
> /srv/dev/
>
> 3) I don't want this to be all fancy. *All of our apps run in their own
> namespaces so we should be able to get by with one or two app dev servers
> and we should be able to use them without a reverse proxy.
>
> Questions comments? *It'd be nice to just throw them all together on a
> couple of hosts in their own namespace. *It'll help find issues with them
> playing together.

I was wondering how our developer workflow would go for the publictest
boxes.. people are using them for development and I wonder what stage
of work we want things to move projects from one set to another.

Scratch development: publictestXX.fedoraproject.org
Integration development: XX.dev.fedoraproject.org
Staging/QA: XX.stg.fedoraproject.org
Production XX.fedoraproject.org

So for the insight project. Work would go on
publictestXX.fedoraproject.org.. and when it was ready to look at for
production we would move it to say staging or dev? When it was ready
for staging we would lock it down and move it to that git tree and
push it out to see how it works in a 'real' environment. After it was
finally tested there we would move to production?

That is the initial picture in my head.. I just want to see if it is accurate.


> * * * *-Mike
>
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>



--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 07-19-2010, 01:29 AM
Mike McGrath
 
Default dev.fedoraproject.org

On Sun, 18 Jul 2010, Stephen John Smoogen wrote:

> On Sat, Jul 17, 2010 at 22:28, Mike McGrath <mmcgrath@redhat.com> wrote:
> > So it is probably time to have a dev.fedoraproject.org. *Why? *Well,
> > toshio had mentioned having others do some of the 'sysadminy' tasks so
> > developers can focus on development.
> >
> > Also Luke had an analogous request wrt community and staging but before I
> > go setting things up some topics for discussion:
> >
> > 1) Security staging and production are identical. *Since production data
> > regularly gets migrated to staging people that have access to one, might
> > as well have access to the other. *Generally our staging environment is
> > mostly used for integration work, some load work as well.
> >
> > 2) Should we run development from rpms that get edited (like live patches)
> > or should we run them from scm(ish) checkouts. *I generally vote for the
> > latter as it feels more useful in a development lifecycle. *But we should
> > come up with a quick standard for how to store this stuff. *something like
> > /srv/dev/
> >
> > 3) I don't want this to be all fancy. *All of our apps run in their own
> > namespaces so we should be able to get by with one or two app dev servers
> > and we should be able to use them without a reverse proxy.
> >
> > Questions comments? *It'd be nice to just throw them all together on a
> > couple of hosts in their own namespace. *It'll help find issues with them
> > playing together.
>
> I was wondering how our developer workflow would go for the publictest
> boxes.. people are using them for development and I wonder what stage
> of work we want things to move projects from one set to another.
>
> Scratch development: publictestXX.fedoraproject.org
> Integration development: XX.dev.fedoraproject.org
> Staging/QA: XX.stg.fedoraproject.org
> Production XX.fedoraproject.org
>
> So for the insight project. Work would go on
> publictestXX.fedoraproject.org.. and when it was ready to look at for
> production we would move it to say staging or dev? When it was ready
> for staging we would lock it down and move it to that git tree and
> push it out to see how it works in a 'real' environment. After it was
> finally tested there we would move to production?
>
> That is the initial picture in my head.. I just want to see if it is accurate.
>

I think you and I are thinking more or less along the same lines except I
might define it more that publictest is more for proof of concept and the
dev environments are more for collaborative development. So there
wouldn't have to be a specific workflow from one to the other. I'd
imagine now that pkgdb, community, fas, etc are all accepted projects that
the would likely not be on a pt host anymore except for say, someone shows
up and wants to make a drastic change to one?

Another example, stuff that we write that's already in our environment
would probably all be worked on from the dev servers. Trac though,
probably not since we don't actually do coding with that. We'd probably
use a pt server as a proof of concept to show that the new version works
with RHEL6, then come up with a migration plan for hosted2 and ultimately
hosted1 (where hosted2 serves as a staging environment in that case)

But really people come by a lot for proof of concept things and more and
more those things are kind of conflicting with the actual "code, test
commit" development work that I think most would agree need to happen.

Side note: there's over 100 accounts on the pt hosts now, we should
probably look into doing a sysadmin-test pruning soon.

-Mike______________________________________________ _
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 07-19-2010, 02:45 AM
Stephen John Smoogen
 
Default dev.fedoraproject.org

On Sun, Jul 18, 2010 at 19:29, Mike McGrath <mmcgrath@redhat.com> wrote:
> On Sun, 18 Jul 2010, Stephen John Smoogen wrote:

> Another example, stuff that we write that's already in our environment
> would probably all be worked on from the dev servers. *Trac though,
> probably not since we don't actually do coding with that. *We'd probably
> use a pt server as a proof of concept to show that the new version works
> with RHEL6, then come up with a migration plan for hosted2 and ultimately
> hosted1 (where hosted2 serves as a staging environment in that case)
>
> But really people come by a lot for proof of concept things and more and
> more those things are kind of conflicting with the actual "code, test
> commit" development work that I think most would agree need to happen.
>
> Side note: there's over 100 accounts on the pt hosts now, we should
> probably look into doing a sysadmin-test pruning soon.

Not just pruning but rebuilds. I am working on the 'project' plan and
to put in a tciket to cover it.



--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 06:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org