Remote drivers are (wrongly) assumed to be global

https://github.com/docker/libnetwork/blob/master/drivers/remote/driver.go#L32
It should be possible to write local-only drivers.

ping @squaremo @tomdee @shettyg. Since you worked on the remote driver implementation more closely, can you please help with defining a proper registration mechanism to determine if the remote driver is interested in being a local scope or global scoped driver ?

It may be difficult to do this without modifications to the plugin subsystem. My best guess at doing without that is to have two kinds of driver; "Implements": ["NetworkDriver"] means a globally scoped driver, and "Implements": ["LocalNetworkDriver"] means a locally scoped driver. (Immediately obvious problem: what does both mean?)
I agree that this is a gap; but I wonder if it is exactly what e.g., kubernetes needs. What assumptions does libnetwork make about locally scoped drivers?

@squaremo i dont think we would need to change the plugin subsystem for this. We could add an explicit call for capability negotiation before having to register the plugin with libnetwork.
If it is a locally scoped driver, then libnetwork will not distribute the network or endpoint information or require a KV store to back these guarantees.

For example, Kubernetes endpoints are not going to be used across hosts.
If we end up implementing our own driver, IPAM decisions are local
decisions. We assign a CIDR per host.  Those IP addresses are not usable on
any other host.
On Wed, Sep 2, 2015 at 4:03 PM, Michael Bridgen<EMAIL_ADDRESS>wrote:

It may be difficult to do this without modifications to the plugin
subsystem. My best guess at doing without that is to have two kinds of
driver; "Implements": ["NetworkDriver"] means a globally scoped driver,
and "Implements": ["LocalNetworkDriver"] means a locally scoped driver.
(Immediately obvious problem: what does both mean?)
I agree that this is a gap; but I wonder if it is exactly what e.g.,
kubernetes needs. What assumptions does libnetwork make about locally
scoped drivers?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137268787.

@thockin as we discussed, this is a good reason to be a local-scoped driver.

@mavenugo
I am likely missing a piece of the puzzle here. A locally scoped remote driver can't work if docker provides uuid instead of names. For e.g:
On host-1:
docker network created -d openvswitch foo
My driver currently receives just a uuid. On a different host, if I run:
docker service publish my-service.foo
I will likely get a "foo" network not found error.
What do you have in mind for a locally scoped driver? Can we get names instead of UUIDs?

Also I think a locally scoped driver will work if commands like "docker network ls" ask the local driver to list networks instead of trying to list UUIDs on its own. The local drivers can provide back UUIDs and names back which is listed by docker. So in theory the local drivers do the job of libkv.

The suggestion from @squaremo sounds sensible to me. The plugin already has to do a handshake to establish its capabilities so adding a different capability for "local" plugins sounds like a good idea

Is "On a different host" compatible with a locally scoped driver?
On Wed, Sep 2, 2015 at 4:29 PM, Gurucharan Shetty<EMAIL_ADDRESS>wrote:

@mavenugo https://github.com/mavenugo
I am likely missing a piece of the puzzle here. A locally scoped remote
driver can't work if docker provides uuid instead of names. For e.g:
On host-1:
docker network created -d openvswitch foo
My driver currently receives just a uuid. On a different host, if I run:
docker service publish my-service.foo
I will likely get a "foo" network not found error.
What do you have in mind for a locally scoped driver? Can we get names
instead of UUIDs?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137272868.

@thockin
So when you say "local" drivers, you are in effect saying that commands like "docker network ls" etc will simply not return information provided to locally scoped driver?
May be if you give an end to end workflow of a locally scoped driver that you have in mind, I will know better.

@shettyg That's an interesting thought. You're treating locally scoped drivers as a way to sidestep multi-host parts of libnetwork. Which as you point out, only works if libnetwork defers more control to the driver.

@shettyg locally scoped driver will make sure libnetwork doesnt synchronize the networks, endpoints and hence yes, it is upto the orchestration system to determine how this is handled across multi-hosts.
In the case of k8s, it will work, because it requires its own subnet space per host and doesnt require L2 mobility. And hence I suggested to open this PR. The drivers can determine what it prefer.

@mavenugo
Got it. In that case, @squaremo suggestion is a nice starting point.

Another thought. Isn't a locally scoped driver same as starting docker daemon with a libkv store that is local only?

@shettyg @squaremo @tomdee i dont think having another plugin endpoint is a good idea. This is a property of the network driver and must be honored as such. Introducing another plugin type will call for more changes to the libnetwork core to look for more plugin types, when the functionality provided by the driver is the same.

Is "On a different host" compatible with a locally scoped driver?

Not in general. Because each host will assume it's acting only locally, it will cons a new UUID for a network it hasn't seen on that host. If "LocalScope" is being used to mean "let me do my own co-ordination", this is going to fail to do the expected thing.

@squaremo correct. bridge driver today is a localscoped driver and it doenst depend on the distributed states. Same I think will work for k8s and other drivers such as macvlan, ipvlan plugins.

@mavenugo Fair point about plugin types; minor shame to have another handshake exchange, but I agree it is better overall.

bridge driver today is a localscoped driver and it doenst depend on the distributed states

Right; this leaves systems that do their own co-ordination high and dry, unfortunately.

@squaremo Are you looking for a notion of cluster to be provided to the drivers by libnetwork?

Are you looking for a notion of cluster to be provided to the drivers by libnetwork?

This wouldn't help, since it would still be the case that drivers only see UUIDs, and these are constructed assuming that Docker's is the only own shared state. So I would lean towards giving the drivers the information they need to do their own co-ordination, which pretty much means the user-supplied names.

Yeah, this would be better.  I can then have kubernetes orchestrate each
individual docker node to create a network "kubernetes" and use that in all
my docker run calls, without having that try to synchronize across nodes
if I happen to have a libkv driver installed for some other reason.
On Wed, Sep 2, 2015 at 5:11 PM, Michael Bridgen<EMAIL_ADDRESS>wrote:

Are you looking for a notion of cluster to be provided to the drivers by
libnetwork?
This wouldn't help, since it would still be the case that drivers only see
UUIDs, and these are constructed assuming that Docker's is the only own
shared state. So I would lean towards giving the drivers the information
they need to do their own co-ordination, which pretty much means the
user-supplied names.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137278183.

@thockin k8s can still do that. If you are planning on using local-scope driber and if the network is created by k8s, it has the mapping between the name <-> network-id across all the hosts.

If I use local-scope driver, won't every node have a different network ID
for the "kubernetes" network?
On Wed, Sep 2, 2015 at 5:26 PM, Madhu Venugopal<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin k8s can still do that. If you are
planning on using local-scope driber and if the network is created by k8s,
it has the mapping between the name <-> network-id across all the hosts.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137281016.

@thockin yes. it will be. just like docker0 bridge today which is different in each host.
If you want the "kubernetes" network to have the exact same ID across all the hosts, then you are essentially looking for a Globally scoped driver.

I don't want Docker to try to manage it globally because we have our own
API.  I don't want to implement generic KV store on top of our structured
API.  I'm forced to use local drivers, but I need the name so I can find
info in my own API.  Your surrogate key is not useful to me.
On Wed, Sep 2, 2015 at 9:40 PM, Madhu Venugopal<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin yes. it will be. just like docker0
bridge today which is different in each host.
If you want the "kubernetes" network to have the exact same ID across all
the hosts, then you are essentially looking for a Globally scoped driver.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137329613.

@thockin can you please help explain what you mean by Your surrogate key is not useful to me. ?
AFAIK, I don't own any surrogate key ;) . jokes apart, I really like to understand your concern here so that we can find a balance between the docker users and kubernetes users. Please note that docker addresses more use-cases than kubernetes.

@tomdee, @shettyg

@shettyg That's an interesting thought. You're treating locally scoped drivers as a way to sidestep multi-host parts of libnetwork. Which as you point out, only works if libnetwork defers more control to the driver.

If this works, then I would not have to think two ways to implement drivers when it runs as a plugin in Kubernetes vs natively as remote driver on libnetwork. Assume that I have KV store available.
I imagine by more control you mean providing network name in the API.

Sorry, that came of snippier than I meant it.
My primary key is the network name.  That's the key my API knows (or will know).  That key exists before I ever call "docker network create".
I don't want docker to try to manage my driver globally because I already have a global control plane.  So I have to use a local driver.
Because I have a local driver, every node is going to "docker network create" and get a different UUID.
When we join a container to a namespace you are only telling me the UUID.  My driver can not use that UUID to look anything up in my own API.
When I start offering multiple Networks, this just gets worse.  I have to make my node-agent keep MORE side-band state that maps the UUID (returned from 'docker network create' right?) to network name and then publish that state to my driver.  I can probably do that, but surely you see how this is a terrible hack just to work around docker.
I know other people have asked for network name - why is docker stonewalling the community on this seemingly tiny thing?

The current side-band hack to retrieve network name is made worse by the fact that the docker+libnetwork remote driver API is synchronous, so the driver cannot query docker during a driver operation or docker will deadlock. Instead the remote driver must cache the UUID and then somehow right after the CreateNetwork() hook request the network name from the docker API. That's obviously racy since there's no guarantee that docker will receive the ListNetworks() request from the driver before libnetwork calls the driver again with CreateEndpoint() or some other call.

@thockin @dcbw @squaremo I think we went way off tangent to the intent of the PR.
@thockin do you still see a need for this issue to be resolved ?
@squaremo Can you please share your thoughts on the remote api implementation for the PR request ?

Yes!  without the ability to have local-scope drivers, I can't use them at all, I think.  But once we have local drivers, I need the name.

The key from my point of view is that (almost all) existing SDN solutions have their own control plane.  So @thockin's comments around control plane, state and KV stores are not Kubernetes specific.  If introducing the idea of a "local" remote driver (yeah, we'll need to think of a better name) can solve that while maintaining a consistent UX for Docker users then that is a huge win for everyone.
To maintain a consistent UX for Docker users though, things like docker network ls need to work across all hosts networked by the underlying SDN without the user having to run the same docker network create on every host. (If that's not the case then we have not maintained a consistent UX, which I believe is one of @mavenugo & @mrjana main focusses for libnetwork.) That in turn means that Docker libnetwork needs to defer the state ownership of network creation (including the network name) to the "local" remote driver.  e.g. When a user runs docker network ls, libnetwork will need to ask the driver for the list of networks.
What do people think?

I think we went way off tangent to the intent of the PR.

If one is very literal about the description, maybe. I think the intention was to make it possible to use libnetwork in a distributed setting without involving all of its kv-store machinery, and from that point of view, the whole discussion was pertinent.

Can you please share your thoughts on the remote api implementation for the PR request ?

I don't mind doing that (at some point), but I think it is necessary to go further and address the other things that came up in discussion.

If one is very literal about the description, maybe. I think the intention was to make it possible to use libnetwork in a distributed setting without involving all of its kv-store machinery,

@squaremo agreed & the reason this issue came about was to support exactly that requirement. We need a PR to back that. We can continue to discuss on the other discussions absolutely, without delaying getting this issue resolved.

That in turn means that Docker libnetwork needs to defer the state ownership of network creation (including the network name) to the "local" remote driver. e.g. When a user runs docker network ls, libnetwork will need to ask the driver for the list of networks.

That would be a more perfect world I suppose, but how about a 1st step, simpler approach of (a) building libnetwork with the simple builtin local KV store (eg https://github.com/docker/libnetwork/pull/466 ) to ensure docker restart keeps networks around, (b) having the control plane/Kubernetes add/remove networks from via the docker API when it wants to, and (c) telling users who do 'docker network add type=' to just Not Do That?
If people would rather take longer and do it right from the start, that's fine too of course...

I'm a big fan of incrementalism, these days

@dcbw sounds good & this issue is one of the first steps. Would be great if someone can back it with a PR.
Can you please elaborate on this

(c) telling users who do 'docker network add type=' to just Not Do That?

(b) having the control plane/Kubernetes add/remove networks from via the docker API when it wants to

Doesn't that run into either the "network only exists locally" problem or the "libnetwork thinks each host has a different network problem?

@squaremo

Doesn't that run into either the "network only exists locally" problem or the "libnetwork thinks each host has a different network" problem?

For a Locally managed networks, its upto the orchestration entity to create network on the "required" hosts and the corresponding driver (which wants to be a locally scoped) to manage the forwarding. Example of such drivers are Mac/IPVlan drivers and the orchestration manages individual host network with appropriate configurations (subnet range to use, etc.)

@dcbw sounds good & this issue is one of the first steps. Would be great if someone can back it with a PR.

I can work on this next week if this sounds like a good first step to @thockin while we hash out the more complete solution of having libnetwork ask the drivers for the network list.  I'm only back on Wed though so maybe somebody will get it before me.

Can you please elaborate on this

There was a concern expressed in the k8s networking google group that if the orchestration layer was responsible for managing the networks, that it could be a problem (and confuse things) if the user was also able to modify/manage those networks through 'docker network' or the docker API, without the orchestration layer being involved.  For example, if the orchestration layer creates network 'blue' with driver "kubernetes", nothing stops a user from modifying blue underneath kubernetes, or even creating their own network 'red' with driver 'kubernetes' that Kubernetes knows nothing about.  The first-pass shortcut I proposed would have no protections against that, so for now we could simply say "dont do that".
But in the future if libnetwork delegates network listing to the drivers, perhaps those driver-defined networks should be immutable by the user from the docker API, since they would be controlled by the orchestration layer and any modifications should happen through it and not via 'docker network' directly.

@dcbw Ultimately the driver gets a chance to say yes or no on network creations and deletions. So in kubernetes case you can implement something like an auth token and pass it as a label to the driver and disallow any network creation or deletion happening out of band which will not have the auth token. I am not suggesting this as a security solution but to block unintentional out of band configuration

@squaremo agreed & the reason this issue came about was to support exactly that requirement. We need a PR to back that. We can continue to discuss on the other discussions absolutely, without delaying getting this issue resolved.

I'm not sure what you're agreeing with there. I meant that fixing the problem described in the title will not meet the requirement. It might not even be a move in the right direction. It seems to me that the division of the model into "GlobalScope", which forces co-ordination, and "LocalScope", which prevents co-ordination, needs reevaluation.

@dcbw

I can work on this next week if this sounds like a good first step to @thockin while we hash out the more complete solution of having libnetwork ask the drivers for the network list. I'm only back on Wed though so maybe somebody will get it before me.

I discussed this longer term desire with @mavenugo on Friday.  He is passionately against libnetwork querying the driver for networks (or other state) due to fundamental architecture beliefs and philosophy that I think is unlikely to shift. So while this proposed PR could be useful for some people, I wouldn't think of it as a step towards libnetwork deferring state ownership to drivers.
@mavenugo - please say if I am misrepresenting our discussion.
Kubernetes could still potentially use this "local-scoped" remote driver to get networking going using libnetwork.  Kubernetes would be responsible for calling network create on every host, and then stitching together the network create calls within the driver to map to a single underlying network.  For this to work the driver needs to get the network name from somewhere.  In the past the libnetwork team have been firmly against passing the network name via the driver API.  I don't know if this thinking has moved on since then, or whether they still want the drivers to use an OOB mechanism to map UIDs to network names.  @mavenugo - can you comment on your latest thinking here?
In either case, it's still pretty kludgy.  I haven't fully thought it through but I think most likely the driver will need to know it is operating in this mode to do the network stitching, so you won't be able to take a standard off the shelf libnetwork driver and expect it to work with k8s without any changes.

Network creation/manipulation should be akin to containers.  Kubernetes
users CAN go around kubernetes and touch them directly, but if they break
it, they get to keep both halves.
As for good first steps, we're very much figuring out which end is up and
what we would have to do vs want to do to defer network management to
docker.  I think we're stuck without this fix, but I am not sure it is
sufficient.
On Sat, Sep 5, 2015 at 11:03 AM, Jana Radhakrishnan <
<EMAIL_ADDRESS>wrote:

@dcbw https://github.com/dcbw Ultimately the driver gets a chance to
say yes or no on network creations and deletions. So in kubernetes case you
can implement something like an auth token and pass it as a label to the
driver and disallow any network creation or deletion happening out of band
which will not have the auth token. I am not suggesting this as a security
solution but to block unintentional out of band configuration
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-137981675.

On Sat, Sep 5, 2015 at 1:10 PM, Alex Pollitt<EMAIL_ADDRESS>wrote:

In either case, it's still pretty kludgy. I haven't fully thought it through but I think most likely the driver will need to know it is operating in this mode to do the network stitching, so you won't be able to take a standard off the shelf libnetwork driver and expect it to work with k8s without any changes.

I agree that it's pretty hack-tacular for things that require some
global coordination but DON'T want libkv.  It might be passable for
truly local-scoped drivers (ipvlan etc).  It's no better or worse that
what we do today with the assumed bridge driver.

@thockin @lxpollitt I really dont understand what you mean by a kludge and a hack. If you tend to mean that libnetwork must make use of driver states to build its own view of the network, then I would say, yes I agree, that is as hack-tacular as it gets. So, I would request folks to give some context behind any such disparaging comments.
The definition of local-scope and global-scope are very clear and simple. local-scoped objects have local significance and will not make use of any of the distributed state services provided by libnetwork. And global-scoped objects automatically gets that service. We absolutely need that in order to provide the user-experience & guarantees that the user expect of Docker. We have 2 very good examples in bridge and overlay drivers. We will add more drivers such as macvlan/ipvlan, etc. which will fall under the local-scoped drivers and it will honor these philosophies.
The point is NOT about libkv and the use of it. Even if libnetwork decides to not make use of libkv or consistent states, there must be a single source of truth. Every layer in the system trying to have its own view of cluster is a bad design to begin with. So, question to @thockin, does k8s tries to understand the state of the cluster from the driver directly (or) is it okay for k8s to have its view of the cluster while the existing SDN solutions (as @lxpollitt put it) can have its own and they are not aligned ?
Again, I think am digressing...
my 2c is to get this issue resolved first as suggested by @dcbw. Delaying this further, we might miss the boat for 1.9 code-freeze if you guys care about that.

what we would have to do vs want to do to defer network management to docker.

Just to check, @thockin: is deferring the network management to docker an inescapable requirement?

I'm not sure what you're agreeing with there. I meant that fixing the problem described in the title will not meet the requirement. It might not even be a move in the right direction. It seems to me that the division of the model into "GlobalScope", which forces co-ordination, and "LocalScope", which prevents co-ordination, needs reevaluation.

@squaremo Forgetting for a moment all the k8s context that is driving this requirement why does this scoping model need reevaluation? We already do this to in-tree drivers i.e bridge is local scoped while overlay is global scoped. There is a bug in the code where in remote drivers don't get to have a say in which scope they belong while in-tree drivers get to and that is wrong. We are merely trying to fix that. Instead of fixing that mismatch independently why are we trying to drag everything along with it?

Forgetting for a moment all the k8s context [...]
Instead of fixing that mismatch independently why are we trying to drag everything along with it?

Perhaps it would be better to change the title and description of this issue, so that they reflect the requirements that motivated it, and the discussion here. Otherwise those will just have to be reiterated.

@mavenugo

The definition of local-scope and global-scope are very clear and simple.

Yes, agreed, they are clear and simple, and are not in any way kludges or hacks.

I really dont understand what you mean by a kludge and a hack.

I mean that the code we are considering writing outside of libnetwork (in k8s and the drivers) if we (the k8s and driver developer community) decide we want to tell libnetwork a driver is local-scoped but actually have the driver map to globally scoped networks in the underlying SDN solution.

So, I would request folks to give some context behind any such disparaging comments.

Apologies if you took these comments to be disparaging.  That was not the intention.  As above, the comments were aimed my view of the code we are considering writing outside of libnetwork.
What I was trying to make clear in the interests of keeping everyone on this thread on the same page (and as I said in my original post, please correct me if I'm misrepresenting) is that the libnetwork team are deeply against having libnetwork defer any state ownership to the driver.  i.e. You don't currently see a future where there is a third type of driver (beyond local-scope and global-scope) where, for example, libnetwork would query the driver for the list of networks in response to a docker network ls command.  It would be really helpful if you could confirm this because I think it's important to avoid confusion and I don't want to misrepresent your position.
I don't think any of this discussion invalidates the desire to add support for local-scoped drivers which @mrjana says is essentially just a straightforward bug fix.

@mavenugo,
Please don't take my remarks as an attack - we're pushing past the bounds
of what libnetwork was designed to handle, so any solutions today are
almost certainly going to be flawed.
The kludge I refer to is that we have a driver that is really a global
driver - it has a cross-node control plane and visibility - but we can not
represent it as a global driver in libnetwork because libnetwork is going
to do the WRONG things.  So we (here's the kludge) lie to libnetwork to
trick it into not doing things we don't want and then go around behind it's
back and do our global control plane.

Even if libnetwork decides to not make use of libkv or consistent states,
there must be a single source of truth.

We agree.  I just don't think one system can declare itself the source of
truth at this point in the lifecycle of the products.

Every layer in the system trying to have its own view of cluster is a bad
design to begin with. So, question to @thockin, does k8s tries to
understand the state of the cluster from the driver directly (or) is it
okay for k8s to have its view of the cluster while the existing SDN
solutions (as @lxpollitt put it) can have its own and they are not aligned ?

We want kubernetes to have enough state to comprehend at a high level what
is being modelled in the system.  It CAN NOT try to be a superset of every
other system nor can it try to declare itself the "one true storage system"
and expect every vendor-provided thing to just conform - this is the
mistake I think libnetwork is making.
People are attached to their working solutions.  You can't yank them away
by diktat.  It may be that, over time, it makes a lot of sense to let
libnetwork manage state for them, asking vendors to start there is a lead
balloon - it ain't gonna float.
Instead you get what you are seeing - vendors (myself included) who will go
to the ends of the earth to do our own thing.    If you
indulge us and help us do sane things we will embrace libnetwork even
more.  Keep libkv for the docker drivers.  Maybe even make it available for
non-core drivers, but don't demand it and don't assume it.
Write the spec such that any driver who doesn't do the equivalent of what
core drivers do with libkv is "out of spec".  But make it the driver's
problem, not libnetwork's.
On Sun, Sep 6, 2015 at 12:04 AM, Madhu Venugopal<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin @lxpollitt
https://github.com/lxpollitt I really dont understand what you mean by
a kludge and a hack. If you tend to mean that libnetwork must make use of
driver states to build its own view of the network, then I would say, yes I
agree, that is as hack-tacular as it gets. So, I would request folks to
give some context behind any such disparaging comments.
The definition of local-scope and global-scope are very clear and simple.
local-scoped objects have local significance and will not make use of any
of the distributed state services provided by libnetwork. And
global-scoped objects automatically gets that service. We absolutely need
that in order to provide the user-experience & guarantees that the user
expect of Docker. We have 2 very good examples in bridge and overlay
drivers. We will add more drivers such as macvlan/ipvlan, etc. which will
fall under the local-scoped drivers and it will honor these philosophies.
The point is NOT about libkv and the use of it. Even if libnetwork decides
to not make use of libkv or consistent states, there must be a single
source of truth. Every layer in the system trying to have its own view of
cluster is a bad design to begin with. So, question to @thockin
https://github.com/thockin, does k8s tries to understand the state of
the cluster from the driver directly (or) is it okay for k8s to have its
view of the cluster while the existing SDN solutions (as @lxpollitt
https://github.com/lxpollitt put it) can have its own and they are not
aligned ?
Again, I think am digressing...
my 2c is to get this issue resolved first as suggested by @dcbw
https://github.com/dcbw. Delaying this further, we might miss the boat
for 1.9 code-freeze if you guys care about that.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-138048447.

@squaremo

is deferring the network management to docker an inescapable requirement?

No, there is a working prototype of kubernetes ditching libnetwork entirely and working around docker's networking.  I don't hate it - it has the advantage of deep simplicity, but the disadvantage of being different from docker.  In order to make a "defer to docker" mode work, we're working through the issues (such as this one :)

Belated and (most likely) obtuse, so apologies in advance for both.
After per-using this thread I'm at a loss on what "global" vs "local" means and for which actions.
"Global" context for me is the docker daemon to which the plugin registers (ergo libnetwork). Which -- at for the platforms that we're working on to integrate, incl. k8s / OpenShift -- is one host.
OTOH k8s  -- and the network plugin-- has a higher-level view (i.e. multi-host) is inherently at odds with that limited view of the universe. The way we solved this (at least for now...) is that each host has a "default" Docker network and some pre-defined network names that are relevant to the plugin and the platform it integrates into (and kept consistent at that level).  Yes, those names map to different NetworkIDs on different node when you do "docker network ls" but we don't care about that (the overlaying platform surely doesn't).
So, what am I missing ?
P.S. Just after typing I realised that maybe my blind spot stems from the fact that there are some attempts  -- e.g. libkv and similar -- to make docker daemon (ergo libnetwork) try to synchronise state across hosts ergo have cross-host visibility. That to me is nothing short of insanity, since most (all ?) overlaying platforms have their own control plane and state distribution mechanisms -- network-wise included. And they sure aren't libkv. Keeping the Docker daemon scope limited to one host makes the plugin "scope" inherently that, with any larger scope & state synchronisation being done by the plugin / platform and inherently invisible to the daemon. My guess is that trying to shoe-horn libkv or somesuch into that will be the fastest way for those platforms in search of more sane alternatives.

@thockin I think this notion that libnetwork is demanding drivers to depend on libkv is not correct. libkv is an internal modular storage system used to store libnetwork/docker's internal state. There is nothing that libnetwork is attempting to force drivers to depend on it. So claiming that libnetwork/docker wants to be the single source of truth is not accurate.
Now docker/libnetwork does provide a networking control plane for people to use and make their distributed app work seamlessly in any network environment. That's what libnetwork was designed for. The goal of network driver interface is to hide this complexity from app developers so that they can define their network in consistent manner without worrying too much about how their connectivity is exactly plumbed at the low level. The goal of network driver is NOT to enable vendor control plane. That is not what it is designed for.
I am certainly not saying that no other control plane should exist for network management. I am just saying what the driver interface was designed for.
Having said all of this there are two options(that I can think of) for the control plane vendors to use:

Divide your control plane into two pieces, the management/control plane and the driver plane.

Provide your favorite interfaces at the management plane to create/delete networks(or any other construct that you want users to manage).
The docker api/ui becomes a hidden interface in this case.
Provide necessary plumbing in the driver plane.
Make drivers local scope and pass everything that is needed to plumb the network path during CreateNetwork/CreateEndpoint/Join calls using labels
Don't use docker network ls. Ask users to use your control plane UI which will be able to provide a list of networks without help from docker

Completely ignore libnetwork and docker's Network/Endpoint abstraction and wrap your favorite control plane around docker and plumb your resources directly into the container's network namespace.

(@mrjana, not sure the formatting of your last post came out as you expected?  The split between the "two options" you mention isn't clear...)

@lxpollitt Fixed it

@FlorianOtel I am not sure why you would prescribe what docker should or shouldn't do. I am not sure if you represent one of the control plane vendors who would move to other "sane" alternatives just because docker provides it's own control plane. If you are, you are welcome to do so. Thanks for your interest in docker.

If labels support gets merged, I think it solves many problems.

@shettyg

If labels support gets merged, I think it solves many problems.

They certainly are needed & they will provide mechanisms for the plugin to work around this but I fail to see how that counts as "solves".

@shettyg

If labels support gets merged, I think it solves many problems.

+1

@FlorianOtel I think you just summarized my (and others) points well.

@mrjana

There is nothing that libnetwork is attempting to force drivers to depend on it. So claiming that libnetwork/docker wants to be the single source of truth is not accurate.

Can I declare my driver as a GlobalScope driver and not have libnetwork try to do stuff with it?  I want to manage my own global state, but I don't see how I can do that - is there an off-switch that I am missing?

The goal of network driver is NOT to enable vendor control plane. That is not what it is designed for.

This seems in direct conflict with what your previous statement.  I can not have my own control plane but I am not forced to use yours.  My choice becomes "your way or no way" - is that the message you intended to convey?

Make drivers local scope and pass everything that is needed to plumb the network path

This is the kludge I mentioned elsewhere.  You're forcing me to lie to your API and work around it.  Is that really the best we can do?

Completely ignore libnetwork and docker's Network/Endpoint abstraction and wrap your favorite control plane around docker and plumb your resources directly into the container's network namespace.

This is the proof-of-concept we have.  It totally ignores docker's concept of Networks.  That seems unfortunate - I am trying to do a better job of embracing Docker, integrating cleanly, and being transparent at all layers of the stack.  But I am not getting very far with it.  :(

@thockin @FlorianOtel as @mrjana pointed out,

@thockin I think this notion that libnetwork is demanding drivers to depend on libkv is not correct. libkv is an internal modular storage system used to store libnetwork/docker's internal state. There is nothing that libnetwork is attempting to force drivers to depend on it. So claiming that libnetwork/docker wants to be the single source of truth is not accurate.

Your summary is incorrect.
So, I would request you to please go over the code and confirm if by using local-scope (which k8s and others seems to be using already) how are the plugins forced into using the libkv ?
Also, I would recommend folks to review #8951 where the discussion for native multi-host networking functionality in docker. If someone feels that docker should not do native multi-host networking, then they can always question the basic premise of this and we can have an open discussion on that. Infact we received similar comments from the vendor community that resulted in a polarizing effect https://github.com/docker/docker/issues/8951#issuecomment-62319706.
If you have not noticed, we are trying very hard to provide a consistent UX & guarantees to the end-users who matter the most for all of us combined. If we try to take short-cuts, some of us can win in the short-term, but all of us will fail in the long-run. I guess it will be very helpful if you can spend some time understanding the libnetwork principles & the intention to serve the end-users without having any vendor bias. At the same time trying to provide simple APIs for vendors to provide the necessary differentiation. So, there seems to be some general lack of education (maybe missing docs ?) on folks  who are not actually knee-deep in the code & making incorrect claims.

@mavenugo

how are the plugins forced into using the libkv ?

I was hoping that we could find something more elegant than declaring any driver with it's own control plane as "local" because of the connotations.  But I guess the point you're making is "Global drivers use libkv.  Local drivers do not.  If you don't want libkv, make your driver Local."  Is that a more accurate summary?
Assuming this bug is fixed, that seems like a workable position.  But now we need the network name, or else I can not link up the ID my driver gets to know with the name my control plane knows.  Is this off the table?  It really makes this approach sort of very hard to work with.

If someone feels that docker should not do native multi-host networking...

I don't think anyone suggested that.  We're only trying to find a way to ALSO support other modes of networking.

@thockin the problem with the discussion is that, some of the claims that are made here isnt actually trying to improve libnetwork to a better place that can help the end-users. Rather, they are short-term views that helps just a handful of drivers.
Case in point :

there are some attempts -- e.g. libkv and similar -- to make docker daemon (ergo libnetwork) try to synchronise state across hosts ergo have cross-host visibility. That to me is nothing short of insanity,

This fundamentally challenges #8951

libnetwork will need to ask the driver for the list of networks.

direct impact on the user experience that libnetwork guarantees to the user.

Can I declare my driver as a GlobalScope driver and not have libnetwork try to do stuff with it? I want to manage my own global state, but I don't see how I can do that - is there an off-switch that I am missing?

GlobalScope by definition means libnetwork needs to have a cluster-wide consistent view of the objects backed by those drivers. Isn't it? Why else would we have the term GlocalScope if libnetwork should not do "stuff" with it? If some other entity is always going to be the control plane why would we even bother designing and implementing libnetwork? Basically you are suggesting docker/libnetwork should not have it's own control plane. Why shouldn't docker try to enable distributed apps as it tried to enable successfully, the monolithic apps.
By definition if you report your driver as GlobalScope you want to depend on libnetwork's control plane. The off-switch is really to use LocalScope so that libnetwork's control plane will not try to do anything with it.

This seems in direct conflict with what your previous statement. I can not have my own control plane but I am not forced to use yours. My choice becomes "your way or no way" - is that the message you intended to convey?

AFAICT I am not conflicting what I said. All I am saying is the driver api was not designed with the goal of enabling vendor control planes. It was designed to integrate various low level networking technologies and as a way to hide those details from app developers. I even said in my previous post that this does not mean we don't want other control planes. In fact we want them all to work with docker. But driver api is not the place to make them work.

This is the kludge I mentioned elsewhere. You're forcing me to lie to your API and work around it. Is that really the best we can do?

This is not a kludge. This is the way you are telling docker to not trigger it's control plane. I am not sure what you mentioned elsewhere but what I am suggesting is that all information flows north -> south using labels which makes all the information that you want to pass from your control plane down to the driver completely opaque to libnetwork. Basically you are muting libnetwork in favor of your control plane and that is fine.

@thockin yes and that is the reason we have to make progress step by step. To me, having this issue resolved and providing the labels support gets us 90% (or even 100%) of all the requirements that we were discussing here.

libnetwork will need to ask the driver for the list of networks.

direct impact on the user experience that libnetwork guarantees to the user.

hmm, I'm not sure I see that.  If installing a FooBar driver suddenly made all of the FooBar networks appear in 'docker network ls', I would actually be pretty impressed - that would be a great user experience.

@thockin

hmm, I'm not sure I see that. If installing a FooBar driver suddenly made all of the FooBar networks appear in 'docker network ls', I would actually be pretty impressed - that would be a great user experience.

What if the foobar driver decides to consume user-created foobaz in some of the nodes, because it feels like it :)

@mavenugo

Also, I would recommend folks to review #8951 where the discussion for native multi-host networking functionality in docker. If someone feels that docker should not do native multi-host networking, then they can always question the basic premise of this and we can have an open discussion on that. Infact we received similar comments from the vendor community that resulted in a polarizing effect docker/docker#8951 (comment).

Point taken. In the spirt of that disclaimer, I work for Nuage Networks and we do have a multi-host SDN solution (which predates Docker).
Back to your point, is not that I think Docker shouldn't have a multi-host solution -- on the contrary.  Yes, I'm aware that my (current) vendor affiliation does make me look biased, but -- hard as it may be to believe -- I do firmly believe that synchronise network state across nodes is a very hard problem. On a second thought, make that I know first hand it is a hard problem, exacerbated by the scale and speed of the state changes imposed by the fast lifecycle for network containers (we have customers spinning up / down mid hundreds Docker containers per one host in fast sequence). The fact that those distributed platforms have their own control plane distribution mechanism, separated but in need to be kept in sync with my / vendor state distribution mechanism is a challenge we know first hand.

This fundamentally challenges #8951

And that I assumes that directs me there, the topic is closed, or both. Understand.
@thockin

This is the kludge I mentioned elsewhere. You're forcing me to lie to your API and work around it. Is that really the best we can do?

Apparently so to me / so far. Let's settle for the ability of driver to select Local (host-only) context, agree that lying to libnetwork is what we can do, let it do its own thing and we all keep going on with our merry lives.

@mrjana

GlobalScope by definition means libnetwork needs to have a cluster-wide consistent view of the objects backed by those drivers. Isn't it?
Why else would we have the term GlocalScope if libnetwork should not do "stuff" with it? If some other entity is always going to be the
control plane why would we even bother designing and implementing libnetwork? Basically you are suggesting docker/libnetwork should
not have it's own control plane. Why shouldn't docker try to enable distributed apps as it tried to enable successfully, the monolithic apps.

Then "Scope" is a complete misnomer.  Had it originally been called useLibKV bool it would not have been a debate.  And no, I dpn't think ANYONE suggested libnetwork (or properly docker) should not have a control plane, just that it should not insiste on being the ONLY control plane.  And before you say it doesn't have to be, please keep in mind that this issue was JUST filed, and the defaulting to global scope (and thereby libkv) has existed for the entirety of the libnetwork development cycle.
Resolution of this issue, combined with the new-found clarity give us 75% of what we need.  Labels and network name will be 24 of the remaining 25%.  I reserve 1% for future problems TBD. :)

@FlorianOtel

Point taken.

We go back a long way. I need no disclaimer from you ;)

What if the foobar driver decides to consume user-created foobaz in some of the nodes, because it feels like it :)

The user installed the foobar driver.  You ought not go too far in protecting a user from themselves - it only makes you insane.

@thockin and that is the exact reason we are trying to keep management plane separated from data-plane. That is the premise of most of the SDN solutions out there. We expect the driver to provide the data-plane guarantees which makes sure the plumbing is done in the best possible way with their own awesome sauce. Management plane should not be mixed with this & that is one of the fundamental point that we are trying to bring across.
If you have not noticed, we just have another proposal on IPAM driver. We heard the end-users requests to keep the IP-Address management composable with the network drivers and hence trying to provide a way for the management of ip-address isolated and flexible for users and vendors alike. We can certainly do much more to various aspects of management plane as well (hint : more coming).

please keep in mind that this issue was JUST filed, and the defaulting to global scope (and thereby libkv) has existed for the entirety of the libnetwork development cycle.

Well, libnetwork is not that old :-) and is still a maturing project. I will be the first to say that we still have a few loose ends like this to tie up. It was certainly not our intention to keep remote plugins as GlobalScope only

please keep in mind that this issue was JUST filed, and the defaulting to global scope (and thereby libkv) has existed for the entirety of the libnetwork development cycle.

Well, libnetwork is not that old :-) and is still a maturing project. I will be the first to say that we still have a few loose ends like this to tie up. It was certainly not our intention to keep remote plugins as GlobalScope only

... and ... we are still in experimental mode ;). So technically, this is a bug that is found during the experimental phase.

@thockin

And no, I don't think ANYONE suggested libnetwork (or properly docker) should not have a control plane, just that it should not insist on being the ONLY control plane.

+1

I even said in my previous post that this does not mean we don't want other control planes. In fact we want them all to work with docker. But driver api is not the place to make them work.

Where is the place to make them work, @mrjana?

@squaremo As I've mentioned in my other posts, the place to make them work is north of docker/libnetwork api, very similar to what k8s is trying to do. Driver api is definitely not the place to expect a gateway to interface into control plane. Control plane doesn't even belong in that layer. Once you have control plane integrated on top of docker api you can have the driver portion of your solution to be plugged into docker using driver api

Most of the problems @thockin & co have been discussing are real problems I have been working around too. The network name, in particular, should be propagated to plugins. I have experimented with a plugin-per-network, plugin-per-tenant-per-network, plugin-that-calls-back-into-docker, etc. None of these solutions are good, even if they all do technically work. Labels and options get us some of the way but we're still playing "fit the square peg into the round hole", looking for a loophole to push a network name in.
Docker should formally clarify the expectations of network plugins from a capability perspective, so we can design one that fits your model. Either that, or open up the capabilities of libnetwork to plugin authors so they can become more than what the creators expect.
I personally favor the latter. :)

@mrjana while it is natural for an orchestrator like Kubernetes to live north of docker, I struggle to see how a pure network implementation could have its control plane do anything north of the api.  Can you expand a bit more how that would work?
Disclaimer: I work on weave Net.

@mrjana

the driver api was not designed with the goal of enabling vendor control planes. It was designed to integrate various low level networking technologies and as a way to hide those details from app developers.

AFAICT everybody who is trying to integrate their networking tech with Docker really wants the former, i.e. integrate both their data plane and control plane. AND they want to do so in a way that fits in with the concepts and UI Docker provides for networking, rather than opting out of that completely.

while it is natural for an orchestrator like Kubernetes to live north of docker, I struggle to see how a pure network implementation could have its control plane do anything north of the api. Can you expand a bit more how that would work?

@bboreham When I mentioned "control plane" I was referring mostly to the management side of the control plane i.e a control plane which has it's own UI/API and has different constructs and abstractions than Dockers Networks/Endpoints etc. For such a control plane, they most certainly need to sit on top of docker and treat docker as a low level ingredient.
For control planes who want to use Docker's Networks/Endpoints abstraction there is no problem, until those control planes try to do things like advertise their drivers as LocalScope but really want GlobalScope behavior. There can't be any middle ground here. Either the solution embraces the  docker's abstractions and API/UI or provides their own abstractions and API/UI north of docker
This was mainly a response to somebody suggesting sending docker network ls to the driver and my response to that is driver api is not the place to extend/customize docker's api/ui
The only thing that can happen in the future is provide a remote api extension point, very similar to ClusterHQ's powerstrip solution if the ecosystem wants management plane hooks. But that's where it should happen if it ever happens and the shape of such an extension point is yet to be determined.

@rade Please see my previous response

So I'm back from vacation and I'd like to summarize my understanding of the discussion so far WRT kubernetes.  It seems like @thockin and k8s would be happy if:

libnetwork should remove the restriction that 'remote' drivers are assumed to be global scope
libnetwork should merge the labels PR so that control-plane-defined data can actually be passed to the driver
libnetwork should pass the network name to the driver in the CreateNetwork request
libnetwork would prefer that consumers that opt out of the docker/libnetwork control plane simply use docker as a mechanism and not UI/API

Does that sound right to everyone?

For control planes who want to use Docker's Networks/Endpoints abstraction there is no problem, until those control planes try to do things like advertise their drivers as LocalScope but really want GlobalScope behavior. There can't be any middle ground here. Either the solution embraces the docker's abstractions and API/UI or provides their own abstractions and API/UI north of docker

As I understand it, "GlobalScope" really means "use Docker/libnetwork control plane", right?  A driver that has its own control plane should currently advertise itself as LocalScope, which is where the confusion stems from.  That driver is actually "global" scope, since it has its own control plane and could be orchestrating multiple instances of docker across nodes, just that docker has no knowledge of that.
So it would be clearer to just deprecate the Scope type, and instead add a new set of flags to the Capability type with one defined value: UseLibnetworkControlPlane.  The 'overlay' driver would set this capability, and remote drivers could opt-in to it as well. All other drivers simply pass nothing for this flag.
If that makes sense I'll do a PR for it?

First I'm sorry that I didn't read all your comments so I may miss something of your talking, I am doing some work on Libnetwork and happen to find a possible solution for this, the related PR is already pushed. The code maybe need a little re-organised, but let's first see if this solution is OK for you.
With that patch, we can use docker daemon --label=com.docker.network.driver.MyNetPlugin.scope=local to set our private network plugin to run in local scope instead of default global scope, this can make the most of label capability.
You guys can have a look and tell me what's your opinion. :)

@WeiZhang555 I would like to thank you for actually pushing a PR to get it resolved :-) Have added comments with my opinion. PTAL.

@mavenugo would you object to changing the Scope definitions into just a single capability for whether or not the plugin wants to use the libnetwork control plane?  I think that would remove some of the confusion we have here.

@dcbw I would say that strictly speaking, local-scoped drivers still use libnetwork's control plane.  e.g. docker network ls will be handled by libnetwork because libnetwork is (currently) the master source of truth.  This is a deliberate design choice by the libnetwork team which they see as key to some subtle UX differences they think are really important.  My view (and I know there will be many others) is that local-scoped and global-scoped do have clear meanings currently and we should respect that.  Of course that's completely separate from the desire many of us have expressed for a third kind of driver that uses libnetwork to provide the UX (as close as possible to existing drivers) but does not use libnetwork's control plane.  I would love to see that happen, but I'm not sure changing the existing scope definitions is the best way of achieving that.  I think it might just confuse things further.

Ok, so per https://github.com/docker/libnetwork/issues/139 libnetwork will never, ever pass the network name down to drivers.  @thockin is that a deal-breaker for the k8s side?

My view (and I know there will be many others) is that local-scoped and global-scoped do have clear meanings currently and we should respect that.

@lxpollitt I'm not sure I'd agree with "clear meanings".  The meaning for GlobalScope is:
// GlobalScope represents the driver capable of providing networking services for containers across hosts

which is certainly true for drivers that do this outside of docker's control plane, yes these drivers have to advertise themselves as LocalScope.  Perhaps just updating the API doc to specify that GlobalScope explicitly opts the driver into the docker control plane would be enough to clarify.

It isn't a deal breaker - we can force users to pass that redundantly as a
label or we can snoop docker in the background.  They are ugly and
unfriendly answers, but if that's what docker thinks is the best way to do
things, that's what we'll do (assuming we pursue libnetwork and kubernetes).
I don't like pushing boulders up hills, so I am going to stop assuming that
it's open to significant changes and instead just work around stuff like
this.
On Thu, Sep 10, 2015 at 9:03 AM, Dan Williams<EMAIL_ADDRESS>wrote:

Ok, so per #139 https://github.com/docker/libnetwork/issues/139
libnetwork will never, ever pass the network name down to drivers.
@thockin https://github.com/thockin is that a deal-breaker for the k8s
side?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/libnetwork/issues/486#issuecomment-139293116.

The labels hack does not work in all cases. Specifically it wouldn't work for dynamically attaching containers to a network, since labels can only be set at container creation time.

@shettyg @squaremo @tomdee i dont think having another plugin endpoint is a good idea. This is a >property of the network driver and must be honored as such. Introducing another plugin type will call >for more changes to the libnetwork core to look for more plugin types, when the functionality provided >by the driver is the same.

I agree with you that the functionality provided by the driver is the same, but why would it call for more changes to libnetwork core?  I have tried to bring it to reality and found that it doesn't need too
many changes.

Hence my suggestion is to add a capability negotiation in the Plugin API & exchange this info,

Do you mean another negotiation after handshake or make negotiation during handshake? Does this need to change the whole plugin mechanism ?

@WeiZhang555 yes, the current changes are small. but am more worried about the long-term impact and the correctness of the design. once we start to treat it as a different plugin, even a slight change made to the driver api in one of the plugin will cause libnetwork to handle 2 different cases at the level of driver interaction. It can quickly become unmanageable.
So, IMO, since this is just a property of network driver, with all other APIs remains exactly the same, the approach must be to keep the plugin-type as the same. But introduce a way to get the driver capability (immediately after the initial plugin handshake). For example, something like
d.call("GetCapability", nil, &api.DriverCapabilityResponse{})
can replace today's code that statically defines the capability as GlobalScope.
               c := driverapi.Capability{
                        Scope: driverapi.GlobalScope,
                }

just before invoking the dc.RegisterDriver here : https://github.com/docker/libnetwork/blob/master/drivers/remote/driver.go#L33
Do you think we can get that done ?

@rade I don't think anybody is talking about container labels here. These are network labels attached to network objects and created during network creation time.

@mavenugo Got your point, you give a really clear and detailed illustration, I'd like to take another shot if you still need this, I think it won't take much time to get that done. :)

Absolutely. Please go ahead.
-Madhu

On Sep 11, 2015, at 8:30 PM, zhangwei_cs<EMAIL_ADDRESS>wrote:
@mavenugo Got your point, you give a really clear and detailed illustration, I'd like to take another shot if you still need this, I think it won't take much time to get that done. :)
—
Reply to this email directly or view it on GitHub.

closing this issue via #516

Now, I'm a little less ignorant on how moby was born. 😉


Change instructions to use a branch not a tag for nephio-test-infra-branch

Fixes https://github.com/nephio-project/nephio/issues/328

/approve

/lgtm


Rule: unresolved-import

This is requested from time to time in OPA, even as far back as 2017!
How imports are handled is unlikely to change in OPA, but we could certainly be more stringent in Regal. Once #282 has landed, it would be simple to aggregate the imports of all policies, and then have an aggregate rule that "resolves" all imports — i..e checks that there is a corresponding module to map to.
Obviously, we'll need to allow exceptions for dynamic / data imports, which would be easy to do either via configuration:
rules:
  custom:
    unresolved-import:
      level: error
      except-imports:
        - data.some.dynamic.stuff

or an ignore directive, like:
# regal ignore:require-imports
import data.some.dynamic.stuff

Making this a custom rule seems like the best way to me, as I don't think we'll want this enabled by default, and the rule likely will need custom configuration in most repos.

The name "require-imports" isn't great, as it likely will have some believe this rule is about enforcing that some packages are always imported... i.e. just that some import ... is present. Naming is hard! Maybe one of:

unresolved-import
import-not-found
other?

We most likely can't "resolve" imports of rules or functions that have been built using dynamic refs, but they aren't common, even less common to import, AND the Rego Style Guide recommends importing packages over rules. Which reminds me, we should have a linter rule for that too.

I've just updated the rule's suggested name to unresolved-import, as that's really what we're trying to get at here.


[FEATURE] support Android scrolling screenshot

Use case
Most pages are a long list, when we need a full screenshot of the long list, we need to merge several screenshots into one, or using the scrolling screenshot feature which is available in many Android devices.
Proposal
I guess, for those native Android app, system can detect scrollable component and enable auto-scroll when capture the screen. But flutter app cannot.
There are two examples of Android reddit app and a simple ListView flutter app.
Reddit example
https://user-images.githubusercontent.com/56487872/124635022-8cf34000-deb9-11eb-87ba-85c69a542b52.mp4
Flutter example
https://user-images.githubusercontent.com/56487872/124635079-9c728900-deb9-11eb-950e-9006b18e1cb2.mp4

Might be worth deduping with https://github.com/flutter/flutter/issues/51313

@nt4f04uNd Yes, that's the same issue. Since I have only one real android device, I'm wondering is this feature not available for all flutter apps, or just blocked on part of devices?
And any progress or plan working with this issue? There's no activity since last year in that issue.

This would require to fake the window height somehow, since Flutter does not paint widgets that are offscreen.  Potentially, doable though.

Yes this feature would be very good

In Android, Google doesn't provide official support for scrolling screenshot/long screenshot. A typical method is finding a scrollable "native Android view", control its scrolling, take screenshots and joint.
Here is a Xiaomi developer's answer(Chinese) about how to realize the feature:
从技术上如何看待长截屏，如何实现这一功能？ - 知乎用户的回答 - 知乎
However, flutter controls most views and render tasks by itself. If these OEM android systems try to detect the scrollable native view, flutter app fails to response. @blasten Even flutter can fake window height, it's not compatible with the function.(I guess)
I'm not sure other OEMs realizing the feature in the same way. Another way is to simulate manual scroll action at center of screen. This way should not have difference between native app and flutter app. But it seems most OEM didn't take this method.
Sure, the best solution is Google support it in original Android SDK.

This could be done entirely in the framework. A picture recorder of the correct size can be used to render the layer tree contents. For larger images, the framework would need to be perform stitching as well.

cc @goderbauer

I can verify that after #100800 (000f4d1) the scrolling screenshot is working on the OnePlus 9T.

Closing this as per the previous comment.


Hook into Prometheus metrics from Crossplane

[ ] Experiment

[ ] Talk with Willi about crossplane dataset

[ ] Add annotations to crossplane operators automatically?

[ ] Test Prometheus metric integration

[ ] Demo

See: https://github.com/crossplane/crossplane/pull/1940

Aha! Link: https://dfds.aha.io/features/CLOUD-75

@wcarlsen send help

Metrics can be enabled via the crossplane helm-chart. However, they are not scraped by our existing kube-prometheus-stack setup because there are no crossplane 'services' exposed
Potential solutions could be to contribute to the upstream helm chart to allow compatibility, or manually create a service and set required annotations. Both or which will require more experimentation

kind: Service
metadata:
  labels:
    scrape-service-metrics: "true"
  name: crossplane
  namespace: crossplane-system
spec:
  ports:
  - port: 8080
    name: metrics
    protocol: TCP
    targetPort: 8080
  selector:
    app: crossplane
    release: crossplane

The data in is pretty much as follows:
HELP workqueue_adds_total Total number of adds handled by workqueue
TYPE workqueue_adds_total counter
HELP workqueue_depth Current depth of workqueue
TYPE workqueue_depth gauge
HELP workqueue_longest_running_processor_seconds How many seconds has the longest running processor for workqueue been running.
TYPE workqueue_longest_running_processor_seconds gauge
HELP workqueue_queue_duration_seconds How long in seconds an item stays in workqueue before being requested
TYPE workqueue_queue_duration_seconds histogram
HELP workqueue_retries_total Total number of retries handled by workqueue
TYPE workqueue_retries_total counter
HELP workqueue_unfinished_work_seconds How many seconds of work has been done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.
TYPE workqueue_unfinished_work_seconds gauge
HELP workqueue_work_duration_seconds How long in seconds processing an item from workqueue takes.
TYPE workqueue_work_duration_seconds histogram

Added task to create service in crossplane module and deploy via eks-pipeline

PR https://github.com/dfds/infrastructure-modules/pull/209


Added getScriptTagsByChunks and getScriptElementsByChunks

Summary
This PR aims to solve #769 by providing an API where you can generate script tags/elements for a specific chunk excluding other non-specified chunks.
Test plan

All other APIs will work as before, they remain unchanged.
For the new APIs, the arguments is now a single object with optional properties.

extraProps works exactly as before either an object or a function
includedChunks allows you to specify which chunks you want to generate tags/elements for

You can see an example usage in the specs that I've added, hopefully those are enough to demonstrate how this works

Notes
I'm open to discussion with the API design here, let me know if there's anything that you would like changed or designer another way.

Good job, but what about getStyleElements and getLinkElements?

https://github.com/gregberge/loadable-components/pull/749

Good job, but what about getStyleElementsByChunks, getStyleTagsByChunks, getLinkElementsByChunks and getLinkTagsByChunks? Maybe we should add includedChunks to the collectChunks?

Sure, I mean we can consider adding those the style and link related functions. In my particular use case I don't have a need and I also tried to think of any cases where the others might be required but couldn't come up with something. So I didn't include them.
Obviously that doesn't mean there's no one else that might not benefit from them. I'm open to adding them to this if we want, or I can also create a subsequent PR if we want to keep this one scoped to just scripts.

Bump

Hey. Sorry for so late reply, got a little overwhelmed with notifications and found this one only now.
There are a few things:

I generally agree that such functionality can be very useful.
However such functionality should be built aside, not a part of the server package
There is ongoing work to extract all webpack-plugin related logic to another package sitting in-between server and webpack-plugin, and decoupling these two from each other

Once the initial scaffolding will be complete I would probably retrofit this PR, especially tests, to that new entity.

Ok yeah that works for me, once the new package is ready to go, I will add this functionality there. Right now we can't upgrade until this is merged, we are experiencing slow downs with webpack v5 that were fixed in v5.15.0 but require functionality that was also removed by that release.
Is there somewhere I should keep looking to see once the new package is ready?


Didn't receive a message on Telegram

Per the instructions, I have written the below-mentioned code. But I didn't receive a message on Telegram.
from devreminder import DevReminder
import time
remind = DevReminder(5350051798,False,5)
remind.me("Example")
time.sleep(6) # Less than 5 does not warn

Hey @arthi-pfizer, I used a free heroku dyno for the project. But heroku is no longer offering free dynos after November 28th. But you can still create your own telegram bot and use its token to receive messages with a few code changes.


Take object, not bool, as param

Throughout our API we take objects. And swagger is unhappy with not
doing so.

LGTM


Invalid log level for error_log in nginx.conf

Issue
nginx.conf specifies invalid log level for error_log and prevents nginx start up.

Fixed in #102


Update Gradle Wrapper from 8.1.1 to 8.2.1

Update Gradle Wrapper from 8.1.1 to 8.2.1.
Read the release notes: https://docs.gradle.org/8.2.1/release-notes.html

The checksums of the Wrapper JAR and the distribution binary have been successfully verified.

Gradle release: 8.2.1
Distribution (-all) zip checksum: 7c3ad722e9b0ce8205b91560fd6ce8296ac3eadf065672242fd73c06b8eeb6ee
Wrapper JAR Checksum: a8451eeda314d0568b5340498b36edf147a8f0d692c5ff58082d477abe9146e4

You can find the reference checksum values at https://gradle.org/release-checksums/

🤖 This PR has been created by the Update Gradle Wrapper action.

Need help? 🤔

If something doesn't look right with this PR please file an issue here.

Superseded by #191


bigchaindb + ethereum example

Hey all - I'm really interested in using bigchaindb as a complementary off-chain storage solution for an Ethereum dAPP but I have no idea where to start. Are there any resources out there that might help me get started? Would this be a good place to provide an example of such an integration?

Hi,
I know that this an old post but I need the same thing,
have you find anything?
Thanks.

hey anyone to help here on the same query?

I too have the same query! No materials to start in the first place


out of date documentation

On the page http://docs.panoptes.apiary.io/#introduction/headers
If-Unmodified-Since should be "If-Match"

This was fixed at somepoint