F5 partitions

[warroyo]

Will this work if the F5 has partitions, i did not see any examples specifying a partition. If it does could you provide a brief example?

[scottdware]

Not at this moment, as it's based around the /Common partition. It's something that I/we plan on tackling in the near future.

[aburnett]

For entities that have a FullPath you should be able to specify an alternate partition like /MyPartition/my-pool. Unfortunately most of the create methods take set parameters which means you would have to create in /Common then Modify to whatever partition you want.

[warroyo]

is there a estimate of when the partitioning will be supported?

[scottdware]

I'm doing the best I can to work at it, but had a recent death in the family and some other things that have taken priority. Hopefully "soon" ;)

[warroyo]

no worries, I am sorry to hear that.

I have been looking into adding the functionality and have started testing some changes locally. I did have a few questions, if I am on the right track I will submit a PR and hopefully that takes a lot of the work off of you.

1. what do you think of the create functions just taking their entire type struct as a parameter? that way the consumer of the library can pass any of the available options in.
2. For the GET calls the best way i could think of to get this to work was by having each function take a new parameter that is a struct that contains all of the available query parameter options and then creates a url query string from the struct and adds it to the url. This is working great and allows for any query paramters to be passed that the F5 supports. my concern here is that this will break any current users of the library.

were you planning on the addition of the partition functionality to require breaking changes? I am fairly new to Go and it doesn't seem like Go supports optional parameters in functions so adding a parameter will cause current implementations to break.

[aburnett]

I vote to have create take a struct. On the fence about having it be a breaking change. On the one hand you can just as easily make new methods that sit beside the existing. On the other that leads to cruft and confusion and people should be vendoring dependencies anyway. Probably leaning towards breaking change.

Can you elaborate on what you mean by the GET calls? Are you talking about how to specify the partition? What if we just treat the parameter as the FullPath if it starts with /?

[warroyo]

I agree that having more methods will just add confusion. Having the Create taking a struct also adds tons of flexibility for tweaking other settings when adding pool members, creating nodes etc.

What I mean by the GET calls is referring to anything that calls the getForEntity method. These are calls that just return info from the F5 and not change anything. The F5 accepts a number of url query parameters that do things such as filtering, limiting results, etc. Here is a link to a page that talks about them. Currently the most of the methods do not take any params and will return results from all partitions etc. It would be very useful to be able to specify these params. I initially thought it would work to just be able to pass them in as a string to the method, but it was not very clean. what I ended up doing is below. it is working for all methods that use the getForEntity.

Example using the pools method:

New struct:

type QueryParms struct {
    Filter               string `url:"$filter,omitempty"`
    Select               string `url:"$select,omitempty"`
    Skip                 int    `url:"$skip,omitempty"`
    Top                  int    `url:"$top,omitempty"`
    ExpandSubCollections bool   `url:"expandSubcollections,omitempty"`
    Options              string `url:"options,omitempty"`
    Ver                  string `url:"ver,omitempty"`
}

Pools method:

func (b *BigIP) Pools(parms *QueryParms) (*Pools, error) {
    var pools Pools
    err, _ := b.getForEntity(&pools, parms, uriLtm, uriPool)
    if err != nil {
        return nil, err
    }

    return &pools, nil
}

There is some extra logic in the APIcall function that properly url encodes the params and add them to url.

calling the method:

 pools, err := f5.Pools(&bigip.QueryParms{Filter: "partition eq mypartition", Top: 4})

The breaking change here is now those methods require at minimum an empty struct to work.

[robertmircea]

Any news about partition support?

[kenmaglio]

@warroyo @robertmircea

As of right now, this package does support Partitions. However, if the Create method does not support it - you have to use the Add and construct the config yourself.

See this pull request conversation: https://github.com/scottdware/go-bigip/pull/69 @scottdware

[kplimack]

this issue has a few birthdays on its belt. are there any updates ?

[carlosedp]

I see partition being a parameter on some tests. Does it mean the library supports different partition for LTM? Thanks!