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

startAddress in ipmi.conf not being respected. #428

Closed
davidblum opened this issue Mar 21, 2016 · 25 comments
Closed

startAddress in ipmi.conf not being respected. #428

davidblum opened this issue Mar 21, 2016 · 25 comments

Comments

@davidblum
Copy link
Contributor

cat /usr/local/collins/conf/ipmi.conf

ipmi {

  passwordLength = 12
  randomUsername = false
  username = "test"
  network = "10.24.8.0/22"
  startAddress = "10.24.10.70"
  gateway = "10.24.8.1"

}

curl -q --basic -H 'ACCEPT:text/plain' -X PUT -u REDACTED:REDACTED "hostname.net:8080/api/asset/test18"

ASSET
        ID      5264
        CREATED 2016-03-21T20:04:57
        TAG     test18
        STATUS  Incomplete
        DELETED null
        UPDATED null
        STATE   null
        TYPE    SERVER_NODE
IPMI
        IPMI_USERNAME   REDACTED
        ID      423
        IPMI_ADDRESS    10.24.8.71
        IPMI_NETMASK    255.255.252.0
        ASSET_ID        5264
        ASSET_TAG       test18
        IPMI_GATEWAY    10.24.8.1
        IPMI_PASSWORD   REDACTED

When defining the IPMI start address in /usr/local/collins/conf/ipmi.conf as illustrated above, we create an asset via api call. The IPMI IP address assigned is one within the specified network range, but much lower than the explicitly stated startAddress.

@william-richard
Copy link
Contributor

Hi @davidblum - I've taken a quick look at this - not sure yet what is going on, but I have a few ideas.

Which version of collins are you currently running?

@davidblum
Copy link
Contributor Author

@Primer42 Thanks for the quick reply!

We are running the most current version, 1.3.0. Cloned from your repo this AM.

@william-richard
Copy link
Contributor

@davidblum Sorry - did you use the released version of 1.3.0 (https://github.com/tumblr/collins/releases/tag/v1.3.0) or did you clone the current master?

@davidblum
Copy link
Contributor Author

@Primer42 Ah, I see what you mean. Cloned from master this am.

@william-richard
Copy link
Contributor

Hmmm ok. I have a few guesses about what may be going on, but I'm not totally sure. I'll keep digging - the IPMI address handling is trying to be a special case of the general IP address allocation, so I'm guessing that somewhere along the way something is getting dropped.

@davidblum
Copy link
Contributor Author

Sounds good.

Let me know what additional information I can provide or anything I can do
to help.

Thanks very much for looking into it.

On Monday, March 21, 2016, William Richard [email protected] wrote:

Hmmm ok. I have a few guesses about what may be going on, but I'm not
totally sure. I'll keep digging - the IPMI address handling is trying to be
a special case of the general IP address allocation, so I'm guessing that
somewhere along the way something is getting dropped.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#428 (comment)

David Blum
DevOps Engineer

@yl3w
Copy link
Contributor

yl3w commented Mar 21, 2016

Did you make that change recently, i.e. have you allocated ip addresses prior to setting a start address?

@davidblum
Copy link
Contributor Author

We have used the start address feature with pools successful in the past.

We have only recently attempted implementing and using the ipmi feature.

On Monday, March 21, 2016, Bhaskar Maddala [email protected] wrote:

Did you make that change recently, i.e. have you allocated ip addresses
prior to setting a start address?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#428 (comment)

David Blum
DevOps Engineer

@yl3w
Copy link
Contributor

yl3w commented Mar 22, 2016

so there are some IPMI addresses allocated current that are prior to the start address because that wasn't enforced initially, correct?

@davidblum
Copy link
Contributor Author

That is correct.

On Monday, March 21, 2016, Bhaskar Maddala [email protected] wrote:

so there are some IPMI addresses allocated current that are prior to the
start address because that wasn't enforced initially, correct?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#428 (comment)

David Blum
DevOps Engineer

@yl3w
Copy link
Contributor

yl3w commented Mar 22, 2016

@Primer42 Will, I spent all of 15-30 s on it, but I think that is the bug.

@davidblum
Copy link
Contributor Author

@maddalab Any update on bug fix?

@yl3w
Copy link
Contributor

yl3w commented Mar 23, 2016

I don't spend any time on Collins as I did as I no longer work at Tumblr. But I'll be happy to check it out when I get some time, don't want to be repeating work the someone at Tumblr might be doing.

@davidblum
Copy link
Contributor Author

@maddalab Ah understood. Thanks for chiming in to narrow down the issue.

@Primer42 Are you currently digging into the issue?

@william-richard
Copy link
Contributor

@davidblum - I've been poking around at this, but I haven't made a lot of progress yet - I'm happy to write a fix once someone finds the bug, I just haven't had a chance to reproduce or figure out what the bug is yet.

@davidblum
Copy link
Contributor Author

@Primer42 - understood. From our side, we have been allocating IPMI addresses to newly created assets. Recently we added the startAddress function, and collins continues to hand out IP's in the same place / range as before. It appears that the function responsible for identifying the minimum address in the range is not taking into account the startAddress.

Does this help narrow down the issue? I can list the steps to recreate it as well if that would be beneficial.

@byxorna
Copy link
Contributor

byxorna commented Mar 24, 2016

FWIW i have replicated this yesterday. I created a new collins instance, wiht ipmi start address 192.168.5.2. I allocated 1 address out of the range (.2), and then changed the start address to 192.168.5.15. After restart, the next IP allocated was 192.168.5.3.

@davidblum
Copy link
Contributor Author

@byxorna That is the exact behavior we are seeing. Glad you were able to replicate.

@yl3w
Copy link
Contributor

yl3w commented Mar 24, 2016

so, confirms what I said initially was the issue, when I looked then it was simply switching a case statement around or adding an additional guard.

@davidblum
Copy link
Contributor Author

@maddalab Is it possible for you to point us to this part of the code so we can attempt to implement you suggestions?

@yl3w
Copy link
Contributor

yl3w commented Mar 25, 2016

@davidblum You want to take a stab at it. I think the change goes here. I'll try it during the weekend, sorry don't have time before then

@davidblum
Copy link
Contributor Author

@maddalab Been poking around, no luck so far. How are things on your end? Did you find any time to test this weekend?

@davidblum
Copy link
Contributor Author

@Primer42 @maddalab

Here is the PR for the bugfix.

#432

@william-richard
Copy link
Contributor

@davidblum - thanks for finding that bug - have you been able to confirm that this is fixed?

@davidblum
Copy link
Contributor Author

@Primer42 Just got a local instance running with all the new code, everything is testing well. I would consider this issue resolved. I'll close this bug now.

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

No branches or pull requests

4 participants