Re: utils/fslock needs to DIAF

[roger peppe]

On 1 December 2015 at 16:43, Nate Finch  wrote:
> I think half the problem is that someone named the package fslock and not
> oslock, so we're stuck asking the wrong question.
>
> If the question is "How do I acquire an OS-level lock for a process?"  The
> answer on Windows is "Use a named mutex".

That's not the question we need to answer here, for the configstore case
anyway. In that case, we really do want to protect access to a shared data
store in the filesystem, so the term "fslock" is appropriate I think.

>  Dave seems to be saying that the
> only problem with unix domain sockets is if you try to think about them like
> files... which may be a result of us thinking too much about the solution
> and not the problem. (again, I'm not an expert, you guys can duke out what
> the best solution is)  I think using hackery with the filesystem locking on
> Windows is a mistake.

Is there something wrong with using the Windows file-exclusive-open
semantics to implement a lock associated with a entity in the file system?
Isn't that what it's for?


> On Tue, Dec 1, 2015 at 4:10 AM roger peppe 
> wrote:
>>
>> So I'm with axw on this one - flock seems like it is a reasonable tool for
>> the job here. FWIW a Unix domain socket also suffers from the "won't
>> work across NFS" problem. Abstract unix domain sockets also
>> have the problem that they won't work with long file paths (what
>> were they thinking?)
>>
>> We have been using github.com/camlistore/lock and although it's not
>> totally ideal (see https://github.com/camlistore/lock/issues/10 )
>> it does the job. Note that it's non-blocking, so a blocking
>> layer above it is necessary, for example see the lockFile
>> function in
>> https://github.com/juju/persistent-cookiejar/blob/master/serialize.go
>>
>> The Windows named mutex thing does sound interesting because
>> it's a blocking API, which is actually what we need. On the other
>> hand, under Windows, files opened for writing are locked by default
>> anyway, so it might be easier just to leverage that property.
>> The camlistore lock code could use some improvement for the
>> Windows platform - we could either fork it, or bradfitz would
>> probably be amenable to a PR.
>>
>>   cheers,
>> rog.
>>
>> On 1 December 2015 at 04:12, Nate Finch  wrote:
>> > I'm not a linux expert, but definitely a named mutex is exactly the
>> > correct
>> > thing to use for Windows.  Using something else for this purpose would
>> > be
>> > very surprising to a Windows dev and much more likely to be buggy.  I
>> > don't
>> > see any reason we need to use the exact same implementation on all OSes
>> > if
>> > there is something that does exactly the right thing without any
>> > finagling.
>> > FWIW, mutexes do die with the process:
>> >
>> > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
>> >
>> > On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
>> >  wrote:
>> >>
>> >> On Tue, Dec 1, 2015 at 9:07 AM David Cheney
>> >> 
>> >> wrote:
>> >>>
>> >>> http://0pointer.de/blog/projects/locking.html
>> >>>
>> >>> In short, opening the same file twice and asserting a lock on it will
>> >>> succeed.
>> >>
>> >>
>> >> Thanks. The article is a bit exasperated. Yes, there are problems to be
>> >> aware of, but it doesn't make them unusable in all cases.
>> >>  - Juju agents don't get installed onto NFS file systems, so doesn't
>> >> matter for the agents.
>> >>  - We're in full control of the files we're locking, we're not locking
>> >> some file like /etc/passwd where some other random bit of code in the
>> >> process is going to open/close it and release the lock by accident.
>> >>  - We don't need byte-range locking.
>> >>
>> >> So only the original uncertainty remains: do we care about clients
>> >> running
>> >> their home directory on an NFS share, where the NFS *server* is too old
>> >> to
>> >> support flock?
>> >>
>> >> Maybe a named mutex on Windows and a domain socket on *NIX is the way
>> >> to
>> >> go. I'm not dead set on flock; I just want something that is simple,
>> >> robust
>> >> and portable.
>> >>
>> >> Cheers,
>> >> Andrew
>> >>
>> >>> On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
>> >>>  wrote:
>> >>> > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> fcntl won't work in threaded go applications, it barely works in
>> >>> >> non
>> >>> >> threaded applications.
>> >>> >
>> >>> >
>> >>> > This is news to me. I've used it plenty in the past, in
>> >>> > multi-threaded
>> >>> > programs. Please point me at relevant literature that explains where
>> >>> > it
>> >>> > doesn't work.
>> >>> >
>> >>> >>
>> >>> >> I'm not interested in "doesn't work on windows" arguments. Yes, we
>> >>> >> have to support windows, but that doesn't mean we have to be
>> >>> 

Re: utils/fslock needs to DIAF

[Nate Finch]

Certainly using Windows' file system lock is appropriate for locking its
files.  I thought the case we were talking about was just abusing that
ability as a generic cross-process lock.

I wasn't aware of how configstore was using fslock.

On Tue, Dec 1, 2015 at 11:58 AM roger peppe 
wrote:

> On 1 December 2015 at 16:43, Nate Finch  wrote:
> > I think half the problem is that someone named the package fslock and not
> > oslock, so we're stuck asking the wrong question.
> >
> > If the question is "How do I acquire an OS-level lock for a process?"
> The
> > answer on Windows is "Use a named mutex".
>
> That's not the question we need to answer here, for the configstore case
> anyway. In that case, we really do want to protect access to a shared data
> store in the filesystem, so the term "fslock" is appropriate I think.
>
> >  Dave seems to be saying that the
> > only problem with unix domain sockets is if you try to think about them
> like
> > files... which may be a result of us thinking too much about the solution
> > and not the problem. (again, I'm not an expert, you guys can duke out
> what
> > the best solution is)  I think using hackery with the filesystem locking
> on
> > Windows is a mistake.
>
> Is there something wrong with using the Windows file-exclusive-open
> semantics to implement a lock associated with a entity in the file system?
> Isn't that what it's for?
>
>
> > On Tue, Dec 1, 2015 at 4:10 AM roger peppe 
> > wrote:
> >>
> >> So I'm with axw on this one - flock seems like it is a reasonable tool
> for
> >> the job here. FWIW a Unix domain socket also suffers from the "won't
> >> work across NFS" problem. Abstract unix domain sockets also
> >> have the problem that they won't work with long file paths (what
> >> were they thinking?)
> >>
> >> We have been using github.com/camlistore/lock and although it's not
> >> totally ideal (see https://github.com/camlistore/lock/issues/10 )
> >> it does the job. Note that it's non-blocking, so a blocking
> >> layer above it is necessary, for example see the lockFile
> >> function in
> >> https://github.com/juju/persistent-cookiejar/blob/master/serialize.go
> >>
> >> The Windows named mutex thing does sound interesting because
> >> it's a blocking API, which is actually what we need. On the other
> >> hand, under Windows, files opened for writing are locked by default
> >> anyway, so it might be easier just to leverage that property.
> >> The camlistore lock code could use some improvement for the
> >> Windows platform - we could either fork it, or bradfitz would
> >> probably be amenable to a PR.
> >>
> >>   cheers,
> >> rog.
> >>
> >> On 1 December 2015 at 04:12, Nate Finch 
> wrote:
> >> > I'm not a linux expert, but definitely a named mutex is exactly the
> >> > correct
> >> > thing to use for Windows.  Using something else for this purpose would
> >> > be
> >> > very surprising to a Windows dev and much more likely to be buggy.  I
> >> > don't
> >> > see any reason we need to use the exact same implementation on all
> OSes
> >> > if
> >> > there is something that does exactly the right thing without any
> >> > finagling.
> >> > FWIW, mutexes do die with the process:
> >> >
> >> >
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
> >> >
> >> > On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
> >> >  wrote:
> >> >>
> >> >> On Tue, Dec 1, 2015 at 9:07 AM David Cheney
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> http://0pointer.de/blog/projects/locking.html
> >> >>>
> >> >>> In short, opening the same file twice and asserting a lock on it
> will
> >> >>> succeed.
> >> >>
> >> >>
> >> >> Thanks. The article is a bit exasperated. Yes, there are problems to
> be
> >> >> aware of, but it doesn't make them unusable in all cases.
> >> >>  - Juju agents don't get installed onto NFS file systems, so doesn't
> >> >> matter for the agents.
> >> >>  - We're in full control of the files we're locking, we're not
> locking
> >> >> some file like /etc/passwd where some other random bit of code in the
> >> >> process is going to open/close it and release the lock by accident.
> >> >>  - We don't need byte-range locking.
> >> >>
> >> >> So only the original uncertainty remains: do we care about clients
> >> >> running
> >> >> their home directory on an NFS share, where the NFS *server* is too
> old
> >> >> to
> >> >> support flock?
> >> >>
> >> >> Maybe a named mutex on Windows and a domain socket on *NIX is the way
> >> >> to
> >> >> go. I'm not dead set on flock; I just want something that is simple,
> >> >> robust
> >> >> and portable.
> >> >>
> >> >> Cheers,
> >> >> Andrew
> >> >>
> >> >>> On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
> >> >>>  wrote:
> >> >>> > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
> >> >>> > 

Re: utils/fslock needs to DIAF

[roger peppe]

So I'm with axw on this one - flock seems like it is a reasonable tool for
the job here. FWIW a Unix domain socket also suffers from the "won't
work across NFS" problem. Abstract unix domain sockets also
have the problem that they won't work with long file paths (what
were they thinking?)

We have been using github.com/camlistore/lock and although it's not
totally ideal (see https://github.com/camlistore/lock/issues/10 )
it does the job. Note that it's non-blocking, so a blocking
layer above it is necessary, for example see the lockFile
function in 
https://github.com/juju/persistent-cookiejar/blob/master/serialize.go

The Windows named mutex thing does sound interesting because
it's a blocking API, which is actually what we need. On the other
hand, under Windows, files opened for writing are locked by default
anyway, so it might be easier just to leverage that property.
The camlistore lock code could use some improvement for the
Windows platform - we could either fork it, or bradfitz would
probably be amenable to a PR.

  cheers,
rog.

On 1 December 2015 at 04:12, Nate Finch  wrote:
> I'm not a linux expert, but definitely a named mutex is exactly the correct
> thing to use for Windows.  Using something else for this purpose would be
> very surprising to a Windows dev and much more likely to be buggy.  I don't
> see any reason we need to use the exact same implementation on all OSes if
> there is something that does exactly the right thing without any finagling.
> FWIW, mutexes do die with the process:
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
>
> On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
>  wrote:
>>
>> On Tue, Dec 1, 2015 at 9:07 AM David Cheney 
>> wrote:
>>>
>>> http://0pointer.de/blog/projects/locking.html
>>>
>>> In short, opening the same file twice and asserting a lock on it will
>>> succeed.
>>
>>
>> Thanks. The article is a bit exasperated. Yes, there are problems to be
>> aware of, but it doesn't make them unusable in all cases.
>>  - Juju agents don't get installed onto NFS file systems, so doesn't
>> matter for the agents.
>>  - We're in full control of the files we're locking, we're not locking
>> some file like /etc/passwd where some other random bit of code in the
>> process is going to open/close it and release the lock by accident.
>>  - We don't need byte-range locking.
>>
>> So only the original uncertainty remains: do we care about clients running
>> their home directory on an NFS share, where the NFS *server* is too old to
>> support flock?
>>
>> Maybe a named mutex on Windows and a domain socket on *NIX is the way to
>> go. I'm not dead set on flock; I just want something that is simple, robust
>> and portable.
>>
>> Cheers,
>> Andrew
>>
>>> On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
>>>  wrote:
>>> > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
>>> > 
>>> > wrote:
>>> >>
>>> >> fcntl won't work in threaded go applications, it barely works in non
>>> >> threaded applications.
>>> >
>>> >
>>> > This is news to me. I've used it plenty in the past, in multi-threaded
>>> > programs. Please point me at relevant literature that explains where it
>>> > doesn't work.
>>> >
>>> >>
>>> >> I'm not interested in "doesn't work on windows" arguments. Yes, we
>>> >> have to support windows, but that doesn't mean we have to be dragged
>>> >> down to it's lowest common denominator.
>>> >
>>> >
>>> > Agreed, if we're actually crippling anything.
>>> >
>>> >>
>>> >> I think it's fine to develop a lock type that does the best available
>>> >> for each platform using conditional compilation.
>>> >
>>> >
>>> > Again, agreed, but only if there's something to be gained by doing
>>> > this. I'm
>>> > still not convinced there is.
>>> >
>>> >> On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins
>>> >>  wrote:
>>> >> > On Tue, Dec 1, 2015 at 8:03 AM David Cheney
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins
>>> >> >>  wrote:
>>> >> >> > On Tue, Dec 1, 2015 at 7:57 AM David Cheney
>>> >> >> > 
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Doesn't look like there is windows support, and it uses fcntl
>>> >> >> >> (flock)
>>> >> >> >> under the hood, which is what we have now.
>>> >> >> >
>>> >> >> >
>>> >> >> > flock isn't the problematic thing Tim is talking about.
>>> >> >> > utils/fslock
>>> >> >> > attempts to create a directory in a known location, and if it
>>> >> >> > succeeds,
>>> >> >> > it
>>> >> >> > "holds the lock". Unlocking means removing the directory.
>>> >> >>
>>> >> >> The problem is if the process dies/exits/goes mental while holding
>>> >> >> the
>>> >> >> lock we get into this existential gridlock where we're not sure if
>>> >> >> the
>>> >> 

Re: utils/fslock needs to DIAF

[William Reade]

Fully agree that fslock is terrible, but strongly against spending
significant engineering effort on it: AFAIAA, core won't need it any more
when we've integrated the agents, and that work is progressing nicely.
Given that, do we *really* need the os-agnostic abstraction we're
discussing?

Cheers
William

On Tue, Dec 1, 2015 at 10:10 AM, roger peppe 
wrote:

> So I'm with axw on this one - flock seems like it is a reasonable tool for
> the job here. FWIW a Unix domain socket also suffers from the "won't
> work across NFS" problem. Abstract unix domain sockets also
> have the problem that they won't work with long file paths (what
> were they thinking?)
>
> We have been using github.com/camlistore/lock and although it's not
> totally ideal (see https://github.com/camlistore/lock/issues/10 )
> it does the job. Note that it's non-blocking, so a blocking
> layer above it is necessary, for example see the lockFile
> function in
> https://github.com/juju/persistent-cookiejar/blob/master/serialize.go
>
> The Windows named mutex thing does sound interesting because
> it's a blocking API, which is actually what we need. On the other
> hand, under Windows, files opened for writing are locked by default
> anyway, so it might be easier just to leverage that property.
> The camlistore lock code could use some improvement for the
> Windows platform - we could either fork it, or bradfitz would
> probably be amenable to a PR.
>
>   cheers,
> rog.
>
> On 1 December 2015 at 04:12, Nate Finch  wrote:
> > I'm not a linux expert, but definitely a named mutex is exactly the
> correct
> > thing to use for Windows.  Using something else for this purpose would be
> > very surprising to a Windows dev and much more likely to be buggy.  I
> don't
> > see any reason we need to use the exact same implementation on all OSes
> if
> > there is something that does exactly the right thing without any
> finagling.
> > FWIW, mutexes do die with the process:
> >
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
> >
> > On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
> >  wrote:
> >>
> >> On Tue, Dec 1, 2015 at 9:07 AM David Cheney  >
> >> wrote:
> >>>
> >>> http://0pointer.de/blog/projects/locking.html
> >>>
> >>> In short, opening the same file twice and asserting a lock on it will
> >>> succeed.
> >>
> >>
> >> Thanks. The article is a bit exasperated. Yes, there are problems to be
> >> aware of, but it doesn't make them unusable in all cases.
> >>  - Juju agents don't get installed onto NFS file systems, so doesn't
> >> matter for the agents.
> >>  - We're in full control of the files we're locking, we're not locking
> >> some file like /etc/passwd where some other random bit of code in the
> >> process is going to open/close it and release the lock by accident.
> >>  - We don't need byte-range locking.
> >>
> >> So only the original uncertainty remains: do we care about clients
> running
> >> their home directory on an NFS share, where the NFS *server* is too old
> to
> >> support flock?
> >>
> >> Maybe a named mutex on Windows and a domain socket on *NIX is the way to
> >> go. I'm not dead set on flock; I just want something that is simple,
> robust
> >> and portable.
> >>
> >> Cheers,
> >> Andrew
> >>
> >>> On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
> >>>  wrote:
> >>> > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> fcntl won't work in threaded go applications, it barely works in non
> >>> >> threaded applications.
> >>> >
> >>> >
> >>> > This is news to me. I've used it plenty in the past, in
> multi-threaded
> >>> > programs. Please point me at relevant literature that explains where
> it
> >>> > doesn't work.
> >>> >
> >>> >>
> >>> >> I'm not interested in "doesn't work on windows" arguments. Yes, we
> >>> >> have to support windows, but that doesn't mean we have to be dragged
> >>> >> down to it's lowest common denominator.
> >>> >
> >>> >
> >>> > Agreed, if we're actually crippling anything.
> >>> >
> >>> >>
> >>> >> I think it's fine to develop a lock type that does the best
> available
> >>> >> for each platform using conditional compilation.
> >>> >
> >>> >
> >>> > Again, agreed, but only if there's something to be gained by doing
> >>> > this. I'm
> >>> > still not convinced there is.
> >>> >
> >>> >> On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins
> >>> >>  wrote:
> >>> >> > On Tue, Dec 1, 2015 at 8:03 AM David Cheney
> >>> >> > 
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins
> >>> >> >>  wrote:
> >>> >> >> > On Tue, Dec 1, 2015 at 7:57 AM David Cheney
> >>> >> >> > 
> >>> >> >> > wrote:
> >>> >> >> >>
> >>> >> >> >> Doesn't 

Re: Juju and cluster managers (like mesos)

[Nicolas Thomas ]

On Mon, Nov 30, 2015 at 7:54 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Samuel
>
>
> Thanks for your answer!
>
> The injection Charm sounds interesting. So Juju manages both k8s and the
> services running on top of k8s? Do you have an example you can show me?
>

​Better than that  a full "dangerous demo"
https://www.youtube.com/watch?v=Q_370CUw5Yk

And the corresponding bundle to test it on any cloud:
https://jujucharms.com/u/tads2015dataart/tads2015-demo/21

​The only thing (provided by Truephone) missing is the actual phone number
to the platform link (you can use SIP or SIP Trunk service supported by
Telscale)..

Enjoy​



> > However, monitoring is an expression of the operation and not the
> model, therefore "can not" be operated by Juju.
>
> Can you explain this a bit more? What do you see as model, what do you see
> as operation, and how do actions and hooks fit into this?
>
>
​The true real life monitoring is best done from the workload perspective
(sessions, trends, link to generic cpu/ram metrics) .. It comes after you
model your architecture and must not dictate the way you model.

BUT Juju have an API allowing to use cleanly modelled scale out
capabilities in Juju to react to your monitoring (this can vary from test,
benchmark, prod, etc...) this is what the demo does if Mesos start to reach
the limits juju extend mesos (and dependencies), same if way underused..  ​

​Hope this makes the intent clearer..​



> > Scaling should not depend on Juju either in our current vision. It's
> not an expression of a model, but rather of how to operate the model.
>
> If I understand correctly, the model (Charms) should specify how a service
> can scale, and an external entity (the user or another service) should
> specify when those scaling actions should be called?
>
> I'd like for bundles to be able to specify a lot more about the
> "macroservice" they deploy. So you could run "juju add-unit" on a bundle,
> and it would scale the required services. Ofcourse, this will have to be a
> lot "smarter" because each macroservice has a number of different ways to
> scale. I think a lot of this functionality can be accomplished if a bundle
> would be able to have actions or hooks... Another use-case would be to
> upgrade all charms in a bundle to versions that are known to work together,
> although I think this is currently possible using the deployer...
>
>
>
> Kind regards
> Merlijn Sebrechts
>
>
> 2015-11-30 16:13 GMT+01:00 Samuel Cozannet 
> :
>
>> Adding Artyom from DataArt who has a lot of very clever ideas about this
>> and recently created a cool autoscaling demo.
>>
>> I'm interested in any follow up given to your work. I share your
>> frustration at containers systems using a so called "orchestration" when
>> the orchestration is really some basic hooks.
>> The consequence of these systems is a total absence of portability
>> between techs (moving from k8s to Swarm or worse Mesos requires a lot of
>> rewriting the core and even sometimes rebuild some of the containers to
>> adapt to the service discovery APIs). Something that Juju wants to address
>> really well.
>>
>> My path so far is to create specific injection charms for k8s and others
>> (Swarm so far). By talking only to the current leader, you kind of create
>> this abstraction you are talking about.
>> That means you can then expose configuration to scale out & in the
>> service by calling the Juju API to reconfigure the service itself.
>> Not a complete solution, but a starting point. The issue with it is that
>> to comply with Juju models, I have to create an injection charm per app,
>> which is additional work on top of containerizing for example.
>> The LXD provider will certainly help in that space, even more when/if LXD
>> become first class citizen in "Container Orchestration Tools".
>>
>> As for monitoring, some charms expose monitoring hooks that can be
>> consumed by other specialized services. As a consequence you can easily
>> integrate not only with service spawned by Juju, but also external systems.
>> However, monitoring is an expression of the operation and not the model,
>> therefore "can not" be operated by Juju.
>>
>> Scaling should not depend on Juju either in our current vision. It's not
>> an expression of a model, but rather of how to operate the model.
>> Therefore, this task should stay outside of Juju, even if it can be
>> operated via Juju's APIs (scale out / in, potentially rolling upgrades in
>> the future).
>>
>> ++
>> Sam
>>
>>
>>
>>
>> --
>> Samuel Cozannet
>> Cloud, Big Data and IoT Strategy Team
>> Business Development - Cloud and ISV Ecosystem
>> Changing the Future of Cloud
>> Ubuntu   / Canonical UK LTD  /
>> Juju 
>> samuel.cozan...@canonical.com
>> mob: +33 616 702 389
>> skype: samnco
>> Twitter: @SaMnCo_23
>> [image: View Samuel Cozannet's profile on LinkedIn]
>> 

Re: utils/fslock needs to DIAF

[David Cheney]

On Tue, Dec 1, 2015 at 8:10 PM, roger peppe  wrote:
> So I'm with axw on this one - flock seems like it is a reasonable tool for
> the job here. FWIW a Unix domain socket also suffers from the "won't
> work across NFS" problem. Abstract unix domain sockets also
> have the problem that they won't work with long file paths (what
> were they thinking?)

This is false, abstract unix domains sockets have nothing to do with
nfs, they don't live on a filesystem. wrt to a long path, don't think
of it as a path, think of it as a per machine key.

> We have been using github.com/camlistore/lock and although it's not
> totally ideal (see https://github.com/camlistore/lock/issues/10 )
> it does the job. Note that it's non-blocking, so a blocking
> layer above it is necessary, for example see the lockFile
> function in 
> https://github.com/juju/persistent-cookiejar/blob/master/serialize.go
>
> The Windows named mutex thing does sound interesting because
> it's a blocking API, which is actually what we need. On the other
> hand, under Windows, files opened for writing are locked by default
> anyway, so it might be easier just to leverage that property.
> The camlistore lock code could use some improvement for the
> Windows platform - we could either fork it, or bradfitz would
> probably be amenable to a PR.
>
>   cheers,
> rog.
>
> On 1 December 2015 at 04:12, Nate Finch  wrote:
>> I'm not a linux expert, but definitely a named mutex is exactly the correct
>> thing to use for Windows.  Using something else for this purpose would be
>> very surprising to a Windows dev and much more likely to be buggy.  I don't
>> see any reason we need to use the exact same implementation on all OSes if
>> there is something that does exactly the right thing without any finagling.
>> FWIW, mutexes do die with the process:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
>>
>> On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
>>  wrote:
>>>
>>> On Tue, Dec 1, 2015 at 9:07 AM David Cheney 
>>> wrote:

 http://0pointer.de/blog/projects/locking.html

 In short, opening the same file twice and asserting a lock on it will
 succeed.
>>>
>>>
>>> Thanks. The article is a bit exasperated. Yes, there are problems to be
>>> aware of, but it doesn't make them unusable in all cases.
>>>  - Juju agents don't get installed onto NFS file systems, so doesn't
>>> matter for the agents.
>>>  - We're in full control of the files we're locking, we're not locking
>>> some file like /etc/passwd where some other random bit of code in the
>>> process is going to open/close it and release the lock by accident.
>>>  - We don't need byte-range locking.
>>>
>>> So only the original uncertainty remains: do we care about clients running
>>> their home directory on an NFS share, where the NFS *server* is too old to
>>> support flock?
>>>
>>> Maybe a named mutex on Windows and a domain socket on *NIX is the way to
>>> go. I'm not dead set on flock; I just want something that is simple, robust
>>> and portable.
>>>
>>> Cheers,
>>> Andrew
>>>
 On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
  wrote:
 > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
 > 
 > wrote:
 >>
 >> fcntl won't work in threaded go applications, it barely works in non
 >> threaded applications.
 >
 >
 > This is news to me. I've used it plenty in the past, in multi-threaded
 > programs. Please point me at relevant literature that explains where it
 > doesn't work.
 >
 >>
 >> I'm not interested in "doesn't work on windows" arguments. Yes, we
 >> have to support windows, but that doesn't mean we have to be dragged
 >> down to it's lowest common denominator.
 >
 >
 > Agreed, if we're actually crippling anything.
 >
 >>
 >> I think it's fine to develop a lock type that does the best available
 >> for each platform using conditional compilation.
 >
 >
 > Again, agreed, but only if there's something to be gained by doing
 > this. I'm
 > still not convinced there is.
 >
 >> On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins
 >>  wrote:
 >> > On Tue, Dec 1, 2015 at 8:03 AM David Cheney
 >> > 
 >> > wrote:
 >> >>
 >> >> On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins
 >> >>  wrote:
 >> >> > On Tue, Dec 1, 2015 at 7:57 AM David Cheney
 >> >> > 
 >> >> > wrote:
 >> >> >>
 >> >> >> Doesn't look like there is windows support, and it uses fcntl
 >> >> >> (flock)
 >> >> >> under the hood, which is what we have now.
 >> >> >
 >> >> >
 >> >> > flock isn't the problematic thing Tim is talking about.

Re: Juju and cluster managers (like mesos)

[Merlijn Sebrechts]

This is exactly what I was looking for! Thank you so much for this! This is
a great way to integrate Juju with Mesos so you get the best of both
worlds...

2015-12-01 12:45 GMT+01:00 Nicolas Thomas  :

>
>
> On Mon, Nov 30, 2015 at 7:54 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi Samuel
>>
>>
>> Thanks for your answer!
>>
>> The injection Charm sounds interesting. So Juju manages both k8s and the
>> services running on top of k8s? Do you have an example you can show me?
>>
>
> ​Better than that  a full "dangerous demo"
> https://www.youtube.com/watch?v=Q_370CUw5Yk
>
> And the corresponding bundle to test it on any cloud:
> https://jujucharms.com/u/tads2015dataart/tads2015-demo/21
>
> ​The only thing (provided by Truephone) missing is the actual phone number
> to the platform link (you can use SIP or SIP Trunk service supported by
> Telscale)..
>
> Enjoy​
>
>
>
>> > However, monitoring is an expression of the operation and not the
>> model, therefore "can not" be operated by Juju.
>>
>> Can you explain this a bit more? What do you see as model, what do you
>> see as operation, and how do actions and hooks fit into this?
>>
>>
> ​The true real life monitoring is best done from the workload perspective
> (sessions, trends, link to generic cpu/ram metrics) .. It comes after you
> model your architecture and must not dictate the way you model.
>
> BUT Juju have an API allowing to use cleanly modelled scale out
> capabilities in Juju to react to your monitoring (this can vary from test,
> benchmark, prod, etc...) this is what the demo does if Mesos start to reach
> the limits juju extend mesos (and dependencies), same if way underused..  ​
>
> ​Hope this makes the intent clearer..​
>
>
>
>> > Scaling should not depend on Juju either in our current vision. It's
>> not an expression of a model, but rather of how to operate the model.
>>
>> If I understand correctly, the model (Charms) should specify how a
>> service can scale, and an external entity (the user or another service)
>> should specify when those scaling actions should be called?
>>
>> I'd like for bundles to be able to specify a lot more about the
>> "macroservice" they deploy. So you could run "juju add-unit" on a bundle,
>> and it would scale the required services. Ofcourse, this will have to be a
>> lot "smarter" because each macroservice has a number of different ways to
>> scale. I think a lot of this functionality can be accomplished if a bundle
>> would be able to have actions or hooks... Another use-case would be to
>> upgrade all charms in a bundle to versions that are known to work together,
>> although I think this is currently possible using the deployer...
>>
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>>
>>
>> 2015-11-30 16:13 GMT+01:00 Samuel Cozannet > >:
>>
>>> Adding Artyom from DataArt who has a lot of very clever ideas about this
>>> and recently created a cool autoscaling demo.
>>>
>>> I'm interested in any follow up given to your work. I share your
>>> frustration at containers systems using a so called "orchestration" when
>>> the orchestration is really some basic hooks.
>>> The consequence of these systems is a total absence of portability
>>> between techs (moving from k8s to Swarm or worse Mesos requires a lot of
>>> rewriting the core and even sometimes rebuild some of the containers to
>>> adapt to the service discovery APIs). Something that Juju wants to address
>>> really well.
>>>
>>> My path so far is to create specific injection charms for k8s and others
>>> (Swarm so far). By talking only to the current leader, you kind of create
>>> this abstraction you are talking about.
>>> That means you can then expose configuration to scale out & in the
>>> service by calling the Juju API to reconfigure the service itself.
>>> Not a complete solution, but a starting point. The issue with it is that
>>> to comply with Juju models, I have to create an injection charm per app,
>>> which is additional work on top of containerizing for example.
>>> The LXD provider will certainly help in that space, even more when/if
>>> LXD become first class citizen in "Container Orchestration Tools".
>>>
>>> As for monitoring, some charms expose monitoring hooks that can be
>>> consumed by other specialized services. As a consequence you can easily
>>> integrate not only with service spawned by Juju, but also external systems.
>>> However, monitoring is an expression of the operation and not the model,
>>> therefore "can not" be operated by Juju.
>>>
>>> Scaling should not depend on Juju either in our current vision. It's not
>>> an expression of a model, but rather of how to operate the model.
>>> Therefore, this task should stay outside of Juju, even if it can be
>>> operated via Juju's APIs (scale out / in, potentially rolling upgrades in
>>> the future).
>>>
>>> ++
>>> Sam
>>>
>>>
>>>
>>>
>>> --
>>> Samuel Cozannet
>>> Cloud, Big Data and IoT Strategy Team

Re: utils/fslock needs to DIAF

[roger peppe]

On 1 December 2015 at 12:34, David Cheney  wrote:
> On Tue, Dec 1, 2015 at 8:10 PM, roger peppe  wrote:
>> So I'm with axw on this one - flock seems like it is a reasonable tool for
>> the job here. FWIW a Unix domain socket also suffers from the "won't
>> work across NFS" problem. Abstract unix domain sockets also
>> have the problem that they won't work with long file paths (what
>> were they thinking?)
>
> This is false, abstract unix domains sockets have nothing to do with
> nfs, they don't live on a filesystem. wrt to a long path, don't think
> of it as a path, think of it as a per machine key.

Exactly. But we're using this locking abstraction to protect files,
so if someone else on a different machine that shares those
files through NFS tries to obtain the lock, they'll erroneously succeed.

In the juju agent case, it doesn't matter because we're sure that
all the clients obtaining the lock live on the same machine.
But this is not necessarily the case with the configstore use
case (consider someone that sets JUJU_HOME to a directory
inside an NFS mount).

Aside: it is of course easy to work around the "long path" problem by
just using a secure hash of the path rather than the path itself

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

Re: utils/fslock needs to DIAF

[Nate Finch]

I think half the problem is that someone named the package fslock and not
oslock, so we're stuck asking the wrong question.

If the question is "How do I acquire an OS-level lock for a process?"  The
answer on Windows is "Use a named mutex".  Dave seems to be saying that the
only problem with unix domain sockets is if you try to think about them
like files... which may be a result of us thinking too much about the
solution and not the problem. (again, I'm not an expert, you guys can duke
out what the best solution is)  I think using hackery with the filesystem
locking on Windows is a mistake.

On Tue, Dec 1, 2015 at 4:10 AM roger peppe 
wrote:

> So I'm with axw on this one - flock seems like it is a reasonable tool for
> the job here. FWIW a Unix domain socket also suffers from the "won't
> work across NFS" problem. Abstract unix domain sockets also
> have the problem that they won't work with long file paths (what
> were they thinking?)
>
> We have been using github.com/camlistore/lock and although it's not
> totally ideal (see https://github.com/camlistore/lock/issues/10 )
> it does the job. Note that it's non-blocking, so a blocking
> layer above it is necessary, for example see the lockFile
> function in
> https://github.com/juju/persistent-cookiejar/blob/master/serialize.go
>
> The Windows named mutex thing does sound interesting because
> it's a blocking API, which is actually what we need. On the other
> hand, under Windows, files opened for writing are locked by default
> anyway, so it might be easier just to leverage that property.
> The camlistore lock code could use some improvement for the
> Windows platform - we could either fork it, or bradfitz would
> probably be amenable to a PR.
>
>   cheers,
> rog.
>
> On 1 December 2015 at 04:12, Nate Finch  wrote:
> > I'm not a linux expert, but definitely a named mutex is exactly the
> correct
> > thing to use for Windows.  Using something else for this purpose would be
> > very surprising to a Windows dev and much more likely to be buggy.  I
> don't
> > see any reason we need to use the exact same implementation on all OSes
> if
> > there is something that does exactly the right thing without any
> finagling.
> > FWIW, mutexes do die with the process:
> >
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx
> >
> > On Mon, Nov 30, 2015 at 8:29 PM Andrew Wilkins
> >  wrote:
> >>
> >> On Tue, Dec 1, 2015 at 9:07 AM David Cheney  >
> >> wrote:
> >>>
> >>> http://0pointer.de/blog/projects/locking.html
> >>>
> >>> In short, opening the same file twice and asserting a lock on it will
> >>> succeed.
> >>
> >>
> >> Thanks. The article is a bit exasperated. Yes, there are problems to be
> >> aware of, but it doesn't make them unusable in all cases.
> >>  - Juju agents don't get installed onto NFS file systems, so doesn't
> >> matter for the agents.
> >>  - We're in full control of the files we're locking, we're not locking
> >> some file like /etc/passwd where some other random bit of code in the
> >> process is going to open/close it and release the lock by accident.
> >>  - We don't need byte-range locking.
> >>
> >> So only the original uncertainty remains: do we care about clients
> running
> >> their home directory on an NFS share, where the NFS *server* is too old
> to
> >> support flock?
> >>
> >> Maybe a named mutex on Windows and a domain socket on *NIX is the way to
> >> go. I'm not dead set on flock; I just want something that is simple,
> robust
> >> and portable.
> >>
> >> Cheers,
> >> Andrew
> >>
> >>> On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins
> >>>  wrote:
> >>> > On Tue, Dec 1, 2015 at 8:57 AM David Cheney
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> fcntl won't work in threaded go applications, it barely works in non
> >>> >> threaded applications.
> >>> >
> >>> >
> >>> > This is news to me. I've used it plenty in the past, in
> multi-threaded
> >>> > programs. Please point me at relevant literature that explains where
> it
> >>> > doesn't work.
> >>> >
> >>> >>
> >>> >> I'm not interested in "doesn't work on windows" arguments. Yes, we
> >>> >> have to support windows, but that doesn't mean we have to be dragged
> >>> >> down to it's lowest common denominator.
> >>> >
> >>> >
> >>> > Agreed, if we're actually crippling anything.
> >>> >
> >>> >>
> >>> >> I think it's fine to develop a lock type that does the best
> available
> >>> >> for each platform using conditional compilation.
> >>> >
> >>> >
> >>> > Again, agreed, but only if there's something to be gained by doing
> >>> > this. I'm
> >>> > still not convinced there is.
> >>> >
> >>> >> On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins
> >>> >>  wrote:
> >>> >> > On Tue, Dec 1, 2015 at 8:03 AM David Cheney
> >>> >> > 
> >>> >>