Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add subgraph insertion #511

Open
milroy opened this issue Sep 4, 2019 · 7 comments
Open

Add subgraph insertion #511

milroy opened this issue Sep 4, 2019 · 7 comments
Labels
elasticity support for elastic scheduling

Comments

@milroy
Copy link
Member

milroy commented Sep 4, 2019

As a first step toward elastic scheduling with k8s, flux-sched needs to handle insertion of subgraphs at a target vertex. This will consist of adding capability to resource-query and/or match.

@dongahn
Copy link
Member

dongahn commented Sep 4, 2019

Sounds good to me!

@milroy
Copy link
Member Author

milroy commented Sep 18, 2019

My first pass effort at this issue uses boost copy_graph. While the time complexity is indicated as O(|V| + |E|), the documentation doesn't specify which graph (parent, subgraph to be inserted, or union) the complexity applies to.

The copy_graph code indicates the vertices and edges of the subgraph to be inserted are added into the parent graph (g_out), which must be a model of MutableGraph.

@dongahn
Copy link
Member

dongahn commented Sep 19, 2019

Sounds reasonable to me.

As far as adding new vertices and edges does not result in resizing of the underlying std::vector, this would be as good as you get. At first I felt a bit nervous to rely on the reading of the source code -- because the implementation can change while the interface stays the same. But at the same time, we don't want to write code when the code is already implemented inside BGL.

As I understood, once a copy is made, you wanted to splice the original and copied graphs for all the connecting vertices?

@milroy
Copy link
Member Author

milroy commented Sep 19, 2019

That's correct, but raises a question: are there cases where the original graph and subgraph will need to have multiple connecting edges? Are you thinking of the case where multiple original graphs need to be connected to multiple subgraphs (e.g. original containment is connected to subgraph containment, and original network is connected to subgraph network)?

I'll consider alternatives to boost::copy_graph as well.

@dongahn
Copy link
Member

dongahn commented Sep 20, 2019

@milroy and I discussed this after our meeting yesterday. Two things:

We agreed it would be better to use attach amd detach instead of our initial grow and shrink because the latter set is already used by the execution system in RFC. We thought about join but it has a different meaning in graph theory.

We also discussed ways to attach a sub graph into the existing graph. It seems whether we do this inside or outside the method, we will have to deserialize the sub graph and walk nodes and edges in each subsystem to attach it comprehensively.

@milroy asked what are the major cases where this sub graph is constructed and we agreed that th is will be

  • subgraph coming from the parent Flux instance (even if a sibling is giving up on a resource set, will go to the parent and come down)
  • external like K2s will capture the currently available resources and serialized then into JGF and pass it to our scheduler
  • users can construct a subgraph and this would be mostly for testing.

@dongahn
Copy link
Member

dongahn commented Oct 2, 2019

@milroy and I chatted about this yesterday. This is also highly related to our work on resiliency (which is my next task to complete). Issue #470.

@dongahn dongahn added the elasticity support for elastic scheduling label Dec 19, 2020
@dongahn
Copy link
Member

dongahn commented Dec 19, 2020

@milroy: I'm going to group together issues that support elasticity with a new label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
elasticity support for elastic scheduling
Projects
None yet
Development

No branches or pull requests

2 participants