Re: Charm snap is now strictly confined

2017-09-14 Thread Domas Monkus 
I'm not completely sure if it's a coincidence, but this seems to have
affected mojo - snap installed mojo and charm fail during the collect phase
(https://bugs.launchpad.net/mojo/+bug/1717089)

Domas

On Fri, Sep 8, 2017 at 9:50 PM, Rick Harding 
wrote:

> +1 awesome work folks.
>
> On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>>
>>
>> On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:
>>
>>> good effort devs!
>>>
>>
>> +1, thanks Cory.
>>
>>
>>>
>>> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>>>
 Greetings,

 I just wanted to make a quick announcement that the charm snap is now
 strictly confined on the stable channel (rev 17).  This fixes issues like
 https://github.com/juju/charm-tools/issues/339 and
 https://github.com/juju/charm-tools/issues/319 and prevents similar
 issues from cropping up in the future.

 In general, this change should be pretty much transparent, with the one
 caveat being that you can only build charms from under your HOME directory.

 --
 Juju mailing list
 j...@lists.ubuntu.com
 Modify settings or unsubscribe at: https://lists.ubuntu.com/
 mailman/listinfo/juju


>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju
>>>
>>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Graduated reviewer: Domas Monkus

2015-04-24 Thread Domas Monkus 
Thanks!

Thank you, Casey and Dimiter for reviewing my reviews all this time!

Domas

On Fri, Apr 24, 2015 at 10:23 AM, Matthew Williams 
matthew.willi...@canonical.com wrote:

 Congratulations Domas!
 On 23 Apr 2015 15:47, Casey Marshall casey.marsh...@canonical.com
 wrote:

 Juju developers,
 I would like to announce Domas Monkus is a fully graduated Juju core
 reviewer. This announcement is really long overdue.. Domas is careful
 and thoughtful in his reviews, his feedback is useful, actionable and
 relevant, and he's landed several significant improvements that
 demonstrate a deep understanding of Juju core design and internals.

 So let's give praise, thanks (and reviews) to Domas, for a job well done!

 -Casey


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Versioned Imports and dependencies.tsv

2014-09-23 Thread Domas Monkus 
Disclaimer: one of the commits mentioned here is mine.

I think I agree with Roger on this - as long as the changes to a package
are backwards compatible, incrementing the version number seems a bit over
the top. To begin with, it would mean quickly incrementing versioned
package versions (would charm.v157 even be considered a version?), lots of
unnecessary changes in the juju codebase each time a dependency is updated
(again, in a backward-compatible way) and in this case godeps and version
packages would start solving the same problem in two not directly
compatible ways.

Domas

On Tue, Sep 23, 2014 at 4:52 PM, roger peppe roger.pe...@canonical.com
wrote:

 On 23 September 2014 13:23, Dimiter Naydenov
 dimiter.nayde...@canonical.com wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi all,
 
  I noticed a recent change in juju/juju bumping the revision of a
  sub-repo (in this case juju/charms), which should be fine if the
  sub-repo wasn't imported with a versioned path
  (github.com/juju/charm.v3). The commit in question is:
 
 https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d
 
  The problem is with gopkg.in/juju/charm.v3 specifically, as there are
  a few other cases of bumping the sub-repo revision in dependencies.tsv
  and not issuing a new version:
 
 https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d
 
 https://github.com/juju/juju/commit/c35c4dfb19544667225a3e4b5141c85ccbc011bd
 
  In fact there is a v4 branch: https://github.com/juju/charm/compare/v4
  which is already 3 commits ahead of v3, but juju-core still uses v3.
 
  My point is, we need to discuss and define a policy how to handle
  dependencies with versioned import paths. From a user's perspective,
  importing gopkg.in/juju/charm.v3 should (AIUI) *always* pull the
  same source and you can rely on it being stable and not need to update
  it until you need something from v3. For all other cases
  (non-versioned paths) we use godeps with handles it nicely, without
  claiming to provide stable versions.

 That's not quite how it works. For versioned import paths, the version
 is about the API, not the exact implementation. It's entirely
 OK to add new (backwardly compatible) features to a package that
 has a versioned import path (see When to change the version in
 http://gopkg.in for details on this).

 We use godeps to guarantee stable builds. That means that
 even in the presence of versioned import paths, we still want
 to pin the dependencies for testing purposes, so that we
 get reproducible tests and builds.

 Thus godeps and use of gopkg.in are orthogonal, and I think
 that the commits you mention look fine to me.

   cheers,
 rog.

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Port ranges - restricting opening and closing ranges

2014-08-05 Thread Domas Monkus 
A follow-up question: should closing a port that was not opened previous to
that result in an error?

Domas


On Fri, Jun 27, 2014 at 2:13 PM, Matthew Williams 
matthew.willi...@canonical.com wrote:

 +1 on an opened-ports hook tool, I've added it to the task list


 On Fri, Jun 27, 2014 at 9:41 AM, William Reade 
 william.re...@canonical.com wrote:

 Agreed. Note, though, that we'll want to give charms a way to know what
 ports they have already opened: I think this is a case where
 look-before-you-leap maybe beats easier-ask-forgiveness-than-permission
 (and the consequent requirement that error messages be parsed...). An
 opened-ports hook tool should do the trick.


 On Thu, Jun 26, 2014 at 9:18 PM, Gustavo Niemeyer gust...@niemeyer.net
 wrote:

 +1 to Mark's point. Handling exact matches is much easier, and does
 not prevent a fancier feature later, if there's ever the need.

 On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen (Canonical.com)
 mark.ramm-christen...@canonical.com wrote:
  My belief is that as long as the error messages are clear, and it is
 easy to
  close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine.
  Of
  course it is nicer if we can do that automatically for you, but I
 don't
  see why we can't add that later, and I think there is a value in
 keeping a
  port-range as an atomic data-object either way.
 
  --Mark Ramm
 
 
  On Thu, Jun 26, 2014 at 2:11 PM, Domas Monkus 
 domas.mon...@canonical.com
  wrote:
 
  Hi,
  me and Matthew Williams are working on support for port ranges in
 juju.
  There is one question that the networking model document does not
 answer
  explicitly and the simplicity (or complexity) of the implementation
 depends
  greatly on that.
 
  Should we only allow units to close exactly the same port ranges that
 they
  have opened? That is, if a unit opens the port range [8000-9000], can
 it
  later close ports [8500-8600], effectively splitting the previously
 opened
  port range in half?
 
  Domas
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 



 --

 gustavo @ http://niemeyer.net

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Port ranges - restricting opening and closing ranges

2014-08-05 Thread Domas Monkus 
Ok, so the behavior would have to be:
opened ports : 80-100

close ports 60-70 - no error (noop)
close ports 60-90 - error (cannot close part of a port range)
close ports 80-100 - no error

I'm starting to think this scenario is preferrable, especially with respect
to the idempotency of charm hooks.

Domas


On Tue, Aug 5, 2014 at 2:45 PM, Kapil Thangavelu 
kapil.thangav...@canonical.com wrote:

 imo, no, its a no-op. the end state is still the same. if its an error,
 and now we have partial failure modes to consider against ranges.




 On Tue, Aug 5, 2014 at 1:25 PM, David Cheney david.che...@canonical.com
 wrote:

 Yes, absolutely.

 On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus domas.mon...@canonical.com
 wrote:
  A follow-up question: should closing a port that was not opened
 previous to
  that result in an error?
 
  Domas
 
 
  On Fri, Jun 27, 2014 at 2:13 PM, Matthew Williams
  matthew.willi...@canonical.com wrote:
 
  +1 on an opened-ports hook tool, I've added it to the task list
 
 
  On Fri, Jun 27, 2014 at 9:41 AM, William Reade
  william.re...@canonical.com wrote:
 
  Agreed. Note, though, that we'll want to give charms a way to know
 what
  ports they have already opened: I think this is a case where
  look-before-you-leap maybe beats
 easier-ask-forgiveness-than-permission (and
  the consequent requirement that error messages be parsed...). An
  opened-ports hook tool should do the trick.
 
 
  On Thu, Jun 26, 2014 at 9:18 PM, Gustavo Niemeyer 
 gust...@niemeyer.net
  wrote:
 
  +1 to Mark's point. Handling exact matches is much easier, and does
  not prevent a fancier feature later, if there's ever the need.
 
  On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen
 (Canonical.com)
  mark.ramm-christen...@canonical.com wrote:
   My belief is that as long as the error messages are clear, and it
 is
   easy to
   close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine.
   Of
   course it is nicer if we can do that automatically for you, but I
   don't
   see why we can't add that later, and I think there is a value in
   keeping a
   port-range as an atomic data-object either way.
  
   --Mark Ramm
  
  
   On Thu, Jun 26, 2014 at 2:11 PM, Domas Monkus
   domas.mon...@canonical.com
   wrote:
  
   Hi,
   me and Matthew Williams are working on support for port ranges in
   juju.
   There is one question that the networking model document does not
   answer
   explicitly and the simplicity (or complexity) of the
 implementation
   depends
   greatly on that.
  
   Should we only allow units to close exactly the same port ranges
 that
   they
   have opened? That is, if a unit opens the port range [8000-9000],
 can
   it
   later close ports [8500-8600], effectively splitting the
 previously
   opened
   port range in half?
  
   Domas
  
   --
   Juju-dev mailing list
   Juju-dev@lists.ubuntu.com
   Modify settings or unsubscribe at:
   https://lists.ubuntu.com/mailman/listinfo/juju-dev
  
  
  
   --
   Juju-dev mailing list
   Juju-dev@lists.ubuntu.com
   Modify settings or unsubscribe at:
   https://lists.ubuntu.com/mailman/listinfo/juju-dev
  
 
 
 
  --
 
  gustavo @ http://niemeyer.net
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev