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
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:
- 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.
- 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.
- 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.
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:
- 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.
- 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.
- 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
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:
- 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.
- 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/
- 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
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:
- 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.
- 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/
- 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
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.
infrastructure@lists.fedoraproject.org