Nginx changes (was Re: Getting started with http-kit & nginx on EC2)

[Ryan Stradling]

I am working on an update to the nginx script for other reasons.  I also notice that package updates needs to be run.  Any best practices on handling this?   Should the crate do it, be left up to the caller and documented, or be an option that is on by default in the settings map?  I am leaning towards the latter.

On May 6, 2013 11:57 PM, "Matthew Chadwick" <math...@gmail.com> wrote:

it works now, after adding java/server-spec to my :extends...

On Tuesday, May 7, 2013 1:28:30 PM UTC+10, Hugo wrote:

Matthew Chadwick <math...@gmail.com> writes:

> ahah the difference was that you were doing (converge {(group) 1} :phase []
> ) whereas I was doing (converge (group-spec :phase [...
>
> Now it starts the install phase, but I get a bunch of 403s like:
>
> http://ap-southeast-2.ec2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl-dev_1.0.1-4ubuntu5.5_amd64.deb  
> 403  Forbidden

That's usually a sign that you need to update the package manager -
(p.actions/package-manager :update)

Hugo

--
You received this message because you are subscribed to the Google Groups "pallet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pallet-clj+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Antoni Batchelli]

I am starting to think that the package manager update decision is a node-wide concern, not crate-wide, e.g., if you are using the version of ubuntu that came out last week, package updates are not needed for your crate, but they will be needed six months from now, or on an older ubuntu. 

Or default to always run package update per-node (bootstrap time?). The problem with always running the updates is that they are slow and now always needed. 

Or maybe some default phase whose invocation is left to the issuer of lift, maybe a default :pkg-update phase.

Toni.

-- 

Antoni Batchelli

Founder palletops.com

- twitter: @tbatchelli , @disclojure

--- email: tbatc...@gmail.com

----- web: tbatchelli.org , disclojure.org

[Hugo Duncan]

Ryan Stradling <ryanst...@gmail.com> writes:

> I also
> notice that package updates needs to be run. Any best practices on
> handling this? Should the crate do it, be left up to the caller and
> documented, or be an option that is on by default in the settings map? I
> am leaning towards the latter.

I hadn't considered making it an optional behaviour via settings.
Considering how often problems with stale packages come up, it seems
that it would be worth making crates do this by default.

It could however be significant work to disable the behaviour via
settings, if you use many crates, so maybe some global way of disabling
package manager updates in crates would be welcome too.

Would be great to hear everyone's opinion on this.

Hugo

[Ryan Stradling]

If there is agreement that this is more than just a crate issue (which there seems to be at least some initial feelings that way), then I feel that that problem should be solved vs pushing it down to the crate level. I am in big favor of making this a node issue over a crate issue as it seems to be an issue more than just one crate will have.

I could picture something like the automated-admin-user for package-updates. I wonder if it would make sense to run it via pallet in the bootstrap phase if some key is set to true. I also wonder if it would make sense to set the key in the image definition? so you would have

{:image {:image-id "" :update-packages true}}.

I guess this would make it be tied to the image and feel that might be the right place? Definitely don't have the specifics all figured out though. Just thinking out loud.

Thanks,
Ryan