[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PHP developers workflow discussion



On Mon, 18 Mar 2013, Vojtech Vitek wrote:

> ----- Original Message -----
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "Vojtech Vitek" <vvitek redhat com>
> > Cc: dev lists openshift redhat com, "Mike McGrath" <mmcgrath redhat com>
> > Sent: Monday, March 18, 2013 3:32:03 PM
> > Subject: Re: PHP developers workflow discussion
> >
> >
> >
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > On Fri, 15 Mar 2013, Vojtech Vitek wrote:
> > > >
> > > > > Hi,
> > > > > this thread is meant to start discussion about the possible
> > > > > improvements
> > > > > for the PHP (and other interpreted scripting languages)
> > > > > developers.
> > > > >
> > > > > 1) Self-modifying apps, built-in installers
> > > > >
> > > > > PHP frameworks often use the self-modifying functionality of
> > > > > it's
> > > > > own
> > > > > source files. Not just for storing the application settings,
> > > > > but
> > > > > also
> > > > > for updating/installing the functionality.
> > > > >
> > > > > As an example, both Wordpress/Drupal have built-in installers
> > > > > that
> > > > > can
> > > > > be used via the administration; so the site admins are able to
> > > > > update/install new plugins and themes on-the-fly.
> > > > >
> > > > > Normally, all the changes are made in the app's source code
> > > > > itself:
> > > > >  Drupal: app-root/repo/php/sites/*/{modules,themes}
> > > > >  Wordpress: app-root/repo/php/wp-content/{plugins,themes}
> > > > >
> > > > > This is nothing we would like on OpenShift, right? Because
> > > > > whenever
> > > > > the Developer git pushes, these changes are all wiped out..
> > > > >
> > > > > So what's the workaround? They could probably use the
> > > > > persistent
> > > > > storage
> > > > > (symlink the directories in git relatively to the
> > > > > $OPENSHIFT_DATA_DIR),
> > > > > - but is that enough? Would that be even maintainable?
> > > > >
> > > >
> > > > This use case doesn't sound like a developer use case to me.
> > > >  This
> > > > sounds
> > > > like someone wanting to run software on openshift.  It's a subtle
> > > > difference I know but this sounds a lot like someone just wanting
> > > > to
> > > > host
> > > > their blog on OpenShift.
> > >
> > > Not necessarily; let me describe the most common usecase for
> > > Drupal:
> > > - Developer installs the Drupal core
> > > - Developer installs Drupal modules to bring new functionality
> > >   (think of each module as library with it's own API and
> > >   dependencies)
> > > - Developer doesn't care about source code of any of the above,
> > >   he just wants it running and up-to-date as a stable framework
> > > - Developer creates new git repository (usually git submodule) in
> > > the
> > >   app-root/repo/php/sites/default/modules/ for each of his custom
> > >   modules... and this is where the development happens
> > >
> > > >
> > > > In that case I think OPENSHIFT_DATA_DIR is approperate *or* a
> > > > community
> > > > cartridge (which doesn't exist yet)
> > > >
> > > > >
> > > > > 2) SFTP to the app-root/repo/
> > > > >
> > > > >  - By the way, this is the default workflow used by the Zend
> > > > >  Studio
> > > > >    while developing the Zend apps on OpenShift right now..
> > > > >
> > > > > I've talked to many PHP developers about their feel and
> > > > > satisfaction
> > > > > with the OpenShift PaaS and most of them told me they really
> > > > > hate
> > > > > the
> > > > > "slow" git push deployment.
> > > > >
> > > > > They can't develop on OpenShift as quickly as they're used to,
> > > > > so
> > > > > they're basically forced to use their own local Apache for
> > > > > development.
> > > > >
> > > > > This is against the whole PaaS idea; and also far-away from the
> > > > > ideal
> > > > > test/production release management.. See
> > > > > https://openshift.redhat.com/community/blogs/release-management-in-the-cloud
> > > > >
> > > > > What the PHP developers call for is usually the SFTP/FTP access
> > > > > to
> > > > > the app-root/repo/ directory using their favorite IDE to be
> > > > > able
> > > > > to make the changes on-the-fly. Why? The thing is, that PHP is
> > > > > kind
> > > > > of those "Try it and see if it works." languages.
> > > > >
> > > > > =
> > > > >
> > > > > So what comes to my mind to improve the usability for the PHP
> > > > > developers
> > > > > (and to be able to use PHP apps with self-modifying
> > > > > functionality)
> > > > > is:
> > > > > - let them access the app-root/repo/ for development (well,
> > > > > they
> > > > > can
> > > > >   do it right now, until they git push and wipe-out all the
> > > > >   changes..)
> > > > > - let them decide if the app-root/repo/ was git repository or
> > > > > not
> > > > > (means do not remove the .git/ metadata when cloning from bare
> > > > > git
> > > > > repo)
> > > > > - let them git commit/push from that gear's repository using
> > > > > SSH
> > > > > - let them git commit/push from Web Console (as in advanced
> > > > > Cloud
> > > > > IDEs)
> > > > > - let them do the above also using the popular Cloud IDEs (eg.
> > > > > Cloud9)
> > > > >
> > > > >
> > > > > We would need of course to think of the possible git conflicts
> > > > > that
> > > > > would come with the app-root/repo/ git repository. But in my
> > > > > opinion,
> > > > > this all would be wort it.
> > > > >
> > > >
> > > > We've talked a great deal about making the developer experience
> > > > better and
> > > > it's something we need to get back to after the cartridge format
> > > > changes
> > > > go down.
> > > >
> > > > So, a couple of things.  They can always symlink
> > > > app-root/repo/php
> > > > somewhere (though as I understand it we should get rid of the
> > > > /php
> > > > at
> > > > some
> > > > point).
> > >
> > > Yes, my plan for php cart v2 is to have the public dir changeable.
> >
> > Can you elaborate on what your plan is there?  There have been
> > several discussions about this - the last I heard here was a strong
> > desire for the cart to infer the correct php directory based on the
> > structure of the git repository.  There should be a default (which
> > folks are pushing for to be www) for new repos, but when someone
> > delivers a repo that has no php dir but index.php in the root, the
> > cart should use the root as the php dir.  If there's a php/ or www/
> > dir with index.php, then the cart would use php or www. If the cart
> > can't determine, it would fall back to either an openshift marker or
> > not.  Is that all feedback you've integrated, or are you earlier
> > along.
>
> The idea of having www/ as default public dir is far better than the
> current php/ directory. The other alternative would be also public_html/
> directory to which many users are used to from most Unix-like hostings.
>
> Honestly, I didn't think of any advanced logic behind that to recognize
> every possible use-case. My plan was to make the httpd.conf (or at least
> part of that) changeable to the developers, so they can change the
> default values, any additional directory mappings or Apache settings
> themselves if they really need to.
>
> The main idea is to give the Developers as much freedom as we can offer
> them. Once we give them ability to change all server contexts
> (meaning also server config and virtual hosts; not just directory context
> and .htaccess), I think then we'll go for the win.
>
> What we have in v1 cart gear now is:
> ./php-5.3/conf.d/openshift.conf (readonly)
> <Directory "/var/lib/openshift/<USER>/app-root/runtime/repo//php">
>   AllowOverride All
> </Directory>
>
> What I'd like to reach in v2 cart gear:
> ./app-root/conf.d/*.conf (writable by developers)
>
> In the best scenario having the symlinks or Includes to the
> ./app-root/repo/.openshift/conf.d/* so every app can have it's Apache
> specific *.conf settings in git.
>
> The question is:
> What are security considerations for not letting the developers touch
> any of the Apache *.conf files? And is there anything we could not be
> able to override (after the mentioned Include directive)?
>

This isn't a security directive, it's a convention.  Letting users change
the files as they want leaves us in a bad spot.  It means we can't add /
change configs in the future (since we don't own them at that point, the
users do).  htaccess makes that easy because there's a clear separation
between what a user defines and what a cartridge writer developers.

	-Mike


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]