alright then. ;)
So, what things do we need:
- rules (somewhat discussed), need to see if we need any more.
- frontend design / coding. Any GUI designers around? or does anyone know any that would be interested in working on this?
- backend design / coding. We may be able to piggyback here on a 'application store' type thing. I'm not sure if/when that might exist. Anyone interested in working on this?
- Some simple formulas we can test without frontend/backend. Herlo made one, I need to poke at it some, but others would be welcome. I think we are going to need a library of things available for reuse in formulas and to figure out structure. Also, are there any common use cases we should try and cover in the first few example formulas?
- Can we build in some QA/testing/docs ? As we go, is there a way to build things so it's easier to test/document?
I think one git repo per formula is likely.
formulas versions would then be 'foo-YYYYMMDD-githash' or something.
I'm going to try and work on a roadmap on the trac site with things we need before 1.0 of the formulas framework and we can see if we can find folks to work on those.
kevin
On Sun, 24 Feb 2013 12:44:04 -0700 Kevin Fenzi kevin@scrye.com wrote:
alright then. ;)
So, what things do we need:
rules (somewhat discussed), need to see if we need any more.
frontend design / coding. Any GUI designers around? or does anyone know any that would be interested in working on this?
backend design / coding. We may be able to piggyback here on a 'application store' type thing. I'm not sure if/when that might exist. Anyone interested in working on this?
Some simple formulas we can test without frontend/backend. Herlo
made one, I need to poke at it some, but others would be welcome. I think we are going to need a library of things available for reuse in formulas and to figure out structure. Also, are there any common use cases we should try and cover in the first few example formulas?
- Can we build in some QA/testing/docs ? As we go, is there a way to build things so it's easier to test/document?
I think one git repo per formula is likely.
formulas versions would then be 'foo-YYYYMMDD-githash' or something.
I'm going to try and work on a roadmap on the trac site with things we need before 1.0 of the formulas framework and we can see if we can find folks to work on those.
so I know the idea of formulas as a way of describing a desktop or an app on the desktop is..... exciting or something to people but it's not what I originally cared about when I heard your idea for formulas.
I was thinking of an easy-to-follow thing a person could download to quickly deploy fedora, in amazon or rackspace or google compute engine, with a particular service or development environment setup and ready to run.
1. so you checkout our git tree 2. you install/download ansible 3. you run: ansible-playbook formula-1/go.yml 4. you enjoy your resuling instance all ready and configured as we described
maybe step 2.5 is you change some config values in the git tree or tell it where to find your keys for aws or rackspace.
but in short - we run these things to let people use fedora for something, probably in the cloud, probably right away.
Rather than worry about guis and all the overhead and assumptions we have to make with that - would you be interested in seeing if we can get some basic traction just w/the above?
-sv
On Wed, 13 Mar 2013 19:44:56 -0400 seth vidal skvidal@fedoraproject.org wrote:
so I know the idea of formulas as a way of describing a desktop or an app on the desktop is..... exciting or something to people but it's not what I originally cared about when I heard your idea for formulas.
I was thinking of an easy-to-follow thing a person could download to quickly deploy fedora, in amazon or rackspace or google compute engine, with a particular service or development environment setup and ready to run.
Sure. I think this is a good use case and an easier one...
- so you checkout our git tree
- you install/download ansible
- you run: ansible-playbook formula-1/go.yml
- you enjoy your resuling instance all ready and configured as we
described
maybe step 2.5 is you change some config values in the git tree or tell it where to find your keys for aws or rackspace.
Or the playbook asks you things or you pass it vars=defaults or the like, yeah.
but in short - we run these things to let people use fedora for something, probably in the cloud, probably right away.
Rather than worry about guis and all the overhead and assumptions we have to make with that - would you be interested in seeing if we can get some basic traction just w/the above?
Absolutely.
I think some parts are common to all setups... git repo setup, signed commits, guidelines about what a formula can/can't do, etc. But we could quite possibly focus on the cloud/non interactive side of things first and build that up and then look at adding other stuff later around that. (ratings, gui, etc).
kevin
On Wed, 13 Mar 2013 21:32:19 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Wed, 13 Mar 2013 19:44:56 -0400 seth vidal skvidal@fedoraproject.org wrote:
so I know the idea of formulas as a way of describing a desktop or an app on the desktop is..... exciting or something to people but it's not what I originally cared about when I heard your idea for formulas.
I was thinking of an easy-to-follow thing a person could download to quickly deploy fedora, in amazon or rackspace or google compute engine, with a particular service or development environment setup and ready to run.
Sure. I think this is a good use case and an easier one...
- so you checkout our git tree
- you install/download ansible
- you run: ansible-playbook formula-1/go.yml
- you enjoy your resuling instance all ready and configured as we
described
maybe step 2.5 is you change some config values in the git tree or tell it where to find your keys for aws or rackspace.
Or the playbook asks you things or you pass it vars=defaults or the like, yeah.
but in short - we run these things to let people use fedora for something, probably in the cloud, probably right away.
Rather than worry about guis and all the overhead and assumptions we have to make with that - would you be interested in seeing if we can get some basic traction just w/the above?
Absolutely.
I think some parts are common to all setups... git repo setup, signed commits, guidelines about what a formula can/can't do, etc. But we could quite possibly focus on the cloud/non interactive side of things first and build that up and then look at adding other stuff later around that. (ratings, gui, etc).
So here's a simple one. I spent the evening working with sam on this one:
https://github.com/skottler/ttrss-ansible
setup tt-rss on an f18 instance.
We need more structure so this can be more readily imported - but it's the basic idea.
On top of f18, deploy a thing, and make it available.
-sv
From: seth vidal skvidal@fedoraproject.org I was thinking of an easy-to-follow thing a person could download to quickly deploy fedora, in amazon or rackspace or google compute engine, with a particular service or development environment setup and ready to run.
- so you checkout our git tree
- you install/download ansible
- you run: ansible-playbook formula-1/go.yml
- you enjoy your resuling instance all ready and configured as we
described
This is what I initially thought the concept was to deliver too, although my interest was more for a SOHO setup than getting all carried away with a AWS/rackspace environment. However, I don't think that would need to change the basics here.
-- John Florian
----- Original Message -----
On Sun, 24 Feb 2013 12:44:04 -0700
Rather than worry about guis and all the overhead and assumptions we have to make with that - would you be interested in seeing if we can get some basic traction just w/the above?
This attitude will bring us right back to where we are now, user-experience-wise.
You can't slap a UI on top afterwards and things will just work. gpk-application is providing a really miserable user experience because it sits on top of a stack that was built without worrying about guis.
The assumptions and constraints coming from the needs of a graphical UI have to be taken into account when designing the infrastructure.
Just saying...
On Thu, 14 Mar 2013 09:05:51 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
----- Original Message -----
On Sun, 24 Feb 2013 12:44:04 -0700
Rather than worry about guis and all the overhead and assumptions we have to make with that - would you be interested in seeing if we can get some basic traction just w/the above?
This attitude will bring us right back to where we are now, user-experience-wise.
You can't slap a UI on top afterwards and things will just work. gpk-application is providing a really miserable user experience because it sits on top of a stack that was built without worrying about guis.
The assumptions and constraints coming from the needs of a graphical UI have to be taken into account when designing the infrastructure.
Just saying...
Matthias,
1. if formulas never gets a gui, I'll be just fine.
2. if formulas only ever works as a way to help people test out and deploy cloud instances and servers, I'll continue to be just fine.
I don't know anyone working in this area who cares about the desktop for this. I know I don't care.
If you care about it, then care about it and do something about it - but I'm not going to wait for you to do so.
-sv
----- Original Message -----
Matthias,
if formulas never gets a gui, I'll be just fine.
if formulas only ever works as a way to help people test out and
deploy cloud instances and servers, I'll continue to be just fine.
I don't know anyone working in this area who cares about the desktop for this. I know I don't care.
If you care about it, then care about it and do something about it - but I'm not going to wait for you to do so.
That doesn't quite jive with the way spot presented formulas and ansible as the new black in his recent presentations, including nice-looking mockups of desktop apps, and whatnot.
If formulas are not going to have any graphical frontend, thats fine with me, but lets just make sure all parties understand the expectations and requirements before we get too far along.
On Thu, 14 Mar 2013 10:37:46 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
That doesn't quite jive with the way spot presented formulas and ansible as the new black in his recent presentations, including nice-looking mockups of desktop apps, and whatnot.
I have no idea what you're talking about here.
If formulas are not going to have any graphical frontend, thats fine with me, but lets just make sure all parties understand the expectations and requirements before we get too far along.
I never said they WOULD NOT have a gui. I said I didn't care.
And I don't know who the parties are, all of the folks who I know who have cared about it are on this list.
Kevin presented formulas at fudcon. I don't think you were there but I am positive of the things that I was interested in with them.
If there's some sort of confusion then let me clear it up: - I am not in charge - I am not making decisions for everyone else - I am not interested in a gui
my world isn't dominated or even significantly influenced by a graphical interface running on fedora. My world is dominated by terminals and a web browser. :)
If formulas is not meant to be useful for me there then that's fine. I'll stop referring to anything as formulas and just keep labeling it as ansible playbooks.
-sv
seth vidal (skvidal@fedoraproject.org) said:
On Thu, 14 Mar 2013 10:37:46 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
That doesn't quite jive with the way spot presented formulas and ansible as the new black in his recent presentations, including nice-looking mockups of desktop apps, and whatnot.
I have no idea what you're talking about here.
Spot's discussion (at DevConf) of an improved software selection screen suggested formulas as a potential backend of that aside from just raw packages.
Now, in some respects it might be better off to have one interface for adding end-user applications to the system (such as that tool) and another for adding services that are exposed to other systems (such as... a wrapper around formulas?) But then you're designing two separate use cases.
(For a server-oriented GUI around this, you could consider something like http://bitnami.org/stacks).
Bill
On Thu, 14 Mar 2013 11:12:23 -0400 Bill Nottingham notting@redhat.com wrote:
seth vidal (skvidal@fedoraproject.org) said:
On Thu, 14 Mar 2013 10:37:46 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
That doesn't quite jive with the way spot presented formulas and ansible as the new black in his recent presentations, including nice-looking mockups of desktop apps, and whatnot.
I have no idea what you're talking about here.
Spot's discussion (at DevConf) of an improved software selection screen suggested formulas as a potential backend of that aside from just raw packages.
Now, in some respects it might be better off to have one interface for adding end-user applications to the system (such as that tool) and another for adding services that are exposed to other systems (such as... a wrapper around formulas?) But then you're designing two separate use cases.
I really have no idea what this tool is purported to look like or who/what is working on it.
I thought formulas was about making it easy and simple for folks to try out software from fedora and to start developing using fedora.
Essentially, to make it easy to try out fedora for the use case where we matter - as a server or a devel platform.
I based my thoughts on my conversations with Kevin (who suggested formulas to begin with). So I don't think I'm out in left field here.
If that's not what formulas is then I'll just walk away from this list and formulas and do the stuff I care about on my own.
(For a server-oriented GUI around this, you could consider something like http://bitnami.org/stacks).
was really hoping for opensourceness but <shrug>
So to make sure I understand you - you're saying b/c bitnami exists we shouldn't bother working on anything like this for fedora?
great...
-sv
On Thu, 14 Mar 2013 11:23:35 -0400 seth vidal skvidal@fedoraproject.org wrote:
I really have no idea what this tool is purported to look like or who/what is working on it.
I thought formulas was about making it easy and simple for folks to try out software from fedora and to start developing using fedora.
Essentially, to make it easy to try out fedora for the use case where we matter - as a server or a devel platform.
I based my thoughts on my conversations with Kevin (who suggested formulas to begin with). So I don't think I'm out in left field here.
So, a bit of history here. (wow, we have history already?)
I originally came up with the idea around spins. spins are horrible and I wanted to come up with a way to no longer have to create them. So, take a electronics-lab user. Now they download a live image we have created and distributed and install it. My thought was if there was a way for them to just download ANY fedora install, install that then we could have something that would install the electronics-lab packages, etc and they would be set.
My next immediate thought is that this could also be wonderfully handy for lots of other cases where there wasn't enough energy for someone to make a spin or where they were too niche. LAMP stack, openstack compute node, the sky's the limit. Many of our users would love ways to install a base 'known good', 'best practices' setup and start from there.
If that's not what formulas is then I'll just walk away from this list and formulas and do the stuff I care about on my own.
Please don't.
(For a server-oriented GUI around this, you could consider something like http://bitnami.org/stacks).
was really hoping for opensourceness but <shrug>
So to make sure I understand you - you're saying b/c bitnami exists we shouldn't bother working on anything like this for fedora?
Interesting. Had not seen that one before.
In any case:
Matthias: Can you elaborate on what you think we need to design into things for the GUI side of things? I think we can be pretty agile here, so while I understand the concern, I don't think we should wait until we have a detailed design document to make anything at all.
Some other questions:
Single git tree? Or tree per formula? A single one could get overlarge, multiple are harder to discover.
kevin
----- Original Message -----
Matthias: Can you elaborate on what you think we need to design into things for the GUI side of things? I think we can be pretty agile here, so while I understand the concern, I don't think we should wait until we have a detailed design document to make anything at all.
If you want formulas to be usable from a UI, there should be sufficient metadata available to display formulas in a meaningful way, and it must be available ahead of time, without downloading megabytes of data on the spot. In general, there should be no network activity unless the user explicitly asked for it.
The api needs to be non-blocking, and e.g. allow searches without taking a bit lock that blocks everything else.
Ideally, the should be a way to obtain progress information for long-lasting operations.
It would also be good to design this as a system service, with a way to authorize privileged operations, while allowing read access to everybody.
On Thu, 14 Mar 2013 11:59:22 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
If you want formulas to be usable from a UI, there should be sufficient metadata available to display formulas in a meaningful way, and it must be available ahead of time, without downloading megabytes of data on the spot. In general, there should be no network activity unless the user explicitly asked for it.
ok.
So, this is talking about the case of the UI being a dedicated GUI app that the end user runs. What about moving as much of that as we can to a web backend/site interface a user interacts with via browser?
That would require network, but then the GUI app doesn't need to search or do all those things, all it needs to be is a layer between the (text only) ansible playbook and the user. Ie, a 'ansible-gui'.
The api needs to be non-blocking, and e.g. allow searches without taking a bit lock that blocks everything else.
If it's a web interface we don't need to worry about that...
Ideally, the should be a way to obtain progress information for long-lasting operations.
ok.
It would also be good to design this as a system service, with a way to authorize privileged operations, while allowing read access to everybody.
Sure, so what do you think of:
Website:
* Search and get info about playbooks * Rate playbooks * Download playbooks * Submit new playbooks * Report bugs
Gui App:
* Shows downloaded playbooks/metadata * Can optionally update them (git pull) * lets user run them (If they have required system permissions) * Asks user input optionally for any variables in the playbook * Reports status to use of playbooks running. * Possibly shows a log or history of formulas run.
A command line app could do the same things (or much the same thing) as the GUI one.
In the mean time I don't see the problem with working on the playbook level, and we can adjust the metadata required or the interface they provide to the gui app/command line app or website backend.
Once we have some playbook/formulas in place, they can be directly usefull for command line people, and we can start building the backend and frontend from that?
Thoughts?
kevin
----- Original Message -----
If it's a web interface we don't need to worry about that...
'web interface' is not a magic bullet that gets you out of considering responsiveness and so on. Waiting in front of a browser window that is not updating is just as frustrating as waiting for a local app...
On Thu, 14 Mar 2013 14:12:35 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
----- Original Message -----
If it's a web interface we don't need to worry about that...
'web interface' is not a magic bullet that gets you out of considering responsiveness and so on. Waiting in front of a browser window that is not updating is just as frustrating as waiting for a local app...
I didn't say it would. The web interface would definitely need to be responsive.
kevin
My two cents. ( Disclaimer: I'm the creator of Ansible and the CTO of http://ansibleworks.com )
Having ways to configure fedora by CLI are immediately valuable to everyone. They immediately reduce complexity in spins, and so on, but also get people in Fedora exposure to configuration management tools. It would be easy to wrap these with something as simple as a makefile and they would not even need to know ansible.
ansible has both a Python API for launching playbooks and a CLI. It has a pluggable callback system for letting people know when things happen. nothing really is missing to enable those kinds of integrations should someone be putting in the effort to develop them.
Any sort of interface can be developed independently of the content and I'm happy to help with advice in that regard, but I'm obviously a lot more interested in content.
--Michael
On Thu, Mar 14, 2013 at 5:08 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 14 Mar 2013 14:12:35 -0400 (EDT) Matthias Clasen mclasen@redhat.com wrote:
----- Original Message -----
If it's a web interface we don't need to worry about that...
'web interface' is not a magic bullet that gets you out of considering responsiveness and so on. Waiting in front of a browser window that is not updating is just as frustrating as waiting for a local app...
I didn't say it would. The web interface would definitely need to be responsive.
kevin
formulas-devel mailing list formulas-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/formulas-devel
On Mar 14, 2013 9:49 AM, "Kevin Fenzi" kevin@scrye.com wrote:
On Thu, 14 Mar 2013 11:23:35 -0400 seth vidal skvidal@fedoraproject.org wrote:
I really have no idea what this tool is purported to look like or who/what is working on it.
I thought formulas was about making it easy and simple for folks to try out software from fedora and to start developing using fedora.
Essentially, to make it easy to try out fedora for the use case where we matter - as a server or a devel platform.
I based my thoughts on my conversations with Kevin (who suggested formulas to begin with). So I don't think I'm out in left field here.
So, a bit of history here. (wow, we have history already?)
I originally came up with the idea around spins. spins are horrible and I wanted to come up with a way to no longer have to create them. So, take a electronics-lab user. Now they download a live image we have created and distributed and install it. My thought was if there was a way for them to just download ANY fedora install, install that then we could have something that would install the electronics-lab packages, etc and they would be set.
My next immediate thought is that this could also be wonderfully handy for lots of other cases where there wasn't enough energy for someone to make a spin or where they were too niche. LAMP stack, openstack compute node, the sky's the limit. Many of our users would love ways to install a base 'known good', 'best practices' setup and start from there.
I have a similar vision. It's attractive to end users, and encouraging predictable deployment makes support easier. It also provides examples of functionality we provide; whether desktop applications or cloud services, a browseable and searchable interface shows people what Fedora can do for them. The cloud use case, as I infer Seth is describing, is an experienced sysadmin that knows what problem they are addressing, knows what solution they want to use, and clones the git repo to check for a Formula to suit. The UI helps the sysadmin that knows the problem and is shopping for a solution. It helps the end user that likes goofing around on their computer and wants some new software to play with. As Matthias said, the difference on the backend is metadata.
If that's not what formulas is then I'll just walk away from this list and formulas and do the stuff I care about on my own.
Please don't.
We're a group - you don't have to do it all. Hell, I only have a basic understanding of Ansible at this point. If you plow on creating playbooks that suit your needs, I'd be happy to add signal to them and polish for presentation. I'd learn a lot doing that, which is my goal for participating in the first place. Defining the metadata early on will help.
Some other questions:
Single git tree? Or tree per formula? A single one could get overlarge, multiple are harder to discover.
kevin
I don't have any great ideas on work flow, but a UI *would* solve the discoverability problem.
--Pete
From: Kevin Fenzi kevin@scrye.com Some other questions:
Single git tree? Or tree per formula? A single one could get overlarge, multiple are harder to discover.
I've not personally used them, so I can't speak to their strengths or weaknesses, but what about git submodules? (see "man git-submodule")
-- John Florian
On Thu, 14 Mar 2013 13:53:01 -0400 John.Florian@dart.biz wrote:
From: Kevin Fenzi kevin@scrye.com Some other questions:
Single git tree? Or tree per formula? A single one could get overlarge, multiple are harder to discover.
I've not personally used them, so I can't speak to their strengths or weaknesses, but what about git submodules? (see "man git-submodule")
Very interesting. Finally had time to sit down and play with them. ;)
I think indeed this could help us. basically this allows you to add other git repos to one at specific states. So, we could have seperate git repos for formulas, then have several 'meta' repos. One for stable, one for test one for devel or something. In each of those you can setup submodules that point to whatever other repos you want and what commit they are on. So:
foo.git - inital created formula
Gets added as a submodule to formulas-dev.git
Once it passes requirements,
Gets added as a submodule to formulas-test.git
each commit that passes whatever requirement, the commit thats pointed to will be changed by a commit to the formulas-test repo.
Gets added as a submodule of formulas.git
etc.
Might work. I will try and write up a process/better expansion of this. ;)
kevin
From: Kevin Fenzi kevin@scrye.com
On Thu, 14 Mar 2013 13:53:01 -0400 John.Florian@dart.biz wrote:
From: Kevin Fenzi kevin@scrye.com Some other questions:
Single git tree? Or tree per formula? A single one could get overlarge, multiple are harder to discover.
I've not personally used them, so I can't speak to their strengths or weaknesses, but what about git submodules? (see "man git-submodule")
Very interesting. Finally had time to sit down and play with them. ;)
I think indeed this could help us. basically this allows you to add other git repos to one at specific states. So, we could have seperate git repos for formulas, then have several 'meta' repos. One for stable, one for test one for devel or something. In each of those you can setup submodules that point to whatever other repos you want and what commit they are on. So:
foo.git - inital created formula
Gets added as a submodule to formulas-dev.git
Once it passes requirements,
Gets added as a submodule to formulas-test.git
each commit that passes whatever requirement, the commit thats pointed to will be changed by a commit to the formulas-test repo.
Gets added as a submodule of formulas.git
etc.
Might work. I will try and write up a process/better expansion of this. ;)
Thanks for taking the time I wish I had to look into that and reporting your findings back here. What you propose does indeed sound like a useful organizational approach. -- John Florian
seth vidal (skvidal@fedoraproject.org) said:
I really have no idea what this tool is purported to look like or who/what is working on it.
I thought formulas was about making it easy and simple for folks to try out software from fedora and to start developing using fedora.
Essentially, to make it easy to try out fedora for the use case where we matter - as a server or a devel platform.
I based my thoughts on my conversations with Kevin (who suggested formulas to begin with). So I don't think I'm out in left field here.
If that's not what formulas is then I'll just walk away from this list and formulas and do the stuff I care about on my own.
(For a server-oriented GUI around this, you could consider something like http://bitnami.org/stacks).
was really hoping for opensourceness but <shrug>
? I'm saying that someone might want to use that as an example of a thing you could build as OSS with Fedora & ansible once we have lots of easy to deploy formulas. Not that we should hook into it bitnami itself; just that that's an example of another player in the vague space.
So to make sure I understand you - you're saying b/c bitnami exists we shouldn't bother working on anything like this for fedora?
No. I'm saying that at some point down the road in the future, someone might want to take the current workflow mentioned ( 'git checkout ; $EDITOR ; ansible', as I understand it) and build a workflow that wraps those steps (GUI, web UI, something else.)
I would suspect as long as it is possible to implement - a way to get a list of available formulas - a way to get a list of frobbable parameters for those formulas, if any - a way to specify input items for those formulas (EC2 creds, or whatever)
then that's sufficient, and even the implementation/specificiation of those might wait until there is an actual user of it.
Bill
formulas-devel@lists.stg.fedorahosted.org
-
Bill Nottingham -
John.Florian＠dart.biz -
Kevin Fenzi -
Matthias Clasen -
Michael DeHaan -
Pete Travis -
Seth Vidal