These appear to me on the surface to be somewhat related. I ran into https://github.com/ansible/ansible/issues/33177 myself today when I thought I might be able to radically simplify some scripts I am writing to spin up disposable kubernetes development environments for the team I am working on using kubespray as a git submodule in one of our repos.
Anyway, I thought I would hit up this list with a couple questions before going off on my own…
First off, I saw this comment from someone who appears to be a developer on the Ansible team. The way it’s worded suggests that there is either ongoing or upcoming planned work on that team to address these issues. If that’s true then maybe I shouldn’t spend any time myself doing something that will likely be superceded by someone more knowledgeable about the codebase to begin with.
Second, if no one is working on this already then how likely would a rookie contributor like myself (who is undaunted by difficulty levels provided the code is well-tested to begin with) to take this on with some focused effort over a weekend or two? Could anyone on this list give me some pointers to get started?
These appear to me on the surface to be somewhat related. I ran into https://github.com/ansible/ansible/issues/33177 myself today when I thought
I might be able to radically simplify some scripts I am writing to spin up
disposable kubernetes development environments for the team I am working on
using kubespray as a git submodule in one of our repos.
Anyway, I thought I would hit up this list with a couple questions before
going off on my own...
First off, I saw this comment from someone who appears to be a developer on
the Ansible team. The way it's worded suggests that there is either ongoing
or upcoming planned work on that team to address these issues. If that's
true then maybe I shouldn't spend any time myself doing something that will
likely be superceded by someone more knowledgeable about the codebase to
begin with.
Yes, that comment is from bcoca and he's currently working on a major
refactor of the code that's 1) caused that bug .. and 2) made it so
difficult to fix/maintain
Effectively, once that work is done we should have a number of bug
fixes able to be closed *and* more maintainable code.
Second, if no one is working on this already then how likely would a rookie
contributor like myself (who is undaunted by difficulty levels provided the
code is well-tested to begin with) to take this on with some focused effort
over a weekend or two? Could anyone on this list give me some pointers to
get started?
Unfortunately this particular strand of bugs is not likely a good
candidate for someone new to Ansible in the current state of that
section of the code, however bcoca is working very hard to change that
through his refactor work so hopefully it won't be so daunting in the
future.
Feel free to reach out anytime, we're always happy to have new contributors!
> Howdy folks!
>
> So I am relatively new to ansible as a user, but I think I've found some
> bugs I would like to try my hand at hacking this weekend:
>
> https://github.com/ansible/ansible/issues/29008
> https://github.com/ansible/ansible/issues/33693
> https://github.com/ansible/ansible/issues/33177
>
> These appear to me on the surface to be somewhat related. I ran into
> https://github.com/ansible/ansible/issues/33177 myself today when I
thought
> I might be able to radically simplify some scripts I am writing to spin
up
> disposable kubernetes development environments for the team I am working
on
> using kubespray as a git submodule in one of our repos.
>
>
> Anyway, I thought I would hit up this list with a couple questions before
> going off on my own...
>
>
> First off, I saw this comment from someone who appears to be a developer
on
> the Ansible team. The way it's worded suggests that there is either
ongoing
> or upcoming planned work on that team to address these issues. If that's
> true then maybe I shouldn't spend any time myself doing something that
will
> likely be superceded by someone more knowledgeable about the codebase to
> begin with.
>
Yes, that comment is from bcoca and he's currently working on a major
refactor of the code that's 1) caused that bug .. and 2) made it so
difficult to fix/maintain
Effectively, once that work is done we should have a number of bug
fixes able to be closed *and* more maintainable code.
Yay!
>
> Second, if no one is working on this already then how likely would a
rookie
> contributor like myself (who is undaunted by difficulty levels provided
the
> code is well-tested to begin with) to take this on with some focused
effort
> over a weekend or two? Could anyone on this list give me some pointers to
> get started?
>
Unfortunately this particular strand of bugs is not likely a good
candidate for someone new to Ansible in the current state of that
section of the code, however bcoca is working very hard to change that
through his refactor work so hopefully it won't be so daunting in the
future.
These kind of complex bugs are exactly the kind of thing that draws me into
a project like Ansible, but I understand your point of view and as a
potential newcomer would prefer not to interfere with work in progress.
Feel free to reach out anytime, we're always happy to have new
contributors!
Thanks for taking the time to respond! As I continue to find use cases for
ansible both at work and at home I do hope to get involved eventually.
I would appreciate any suggestions for alternative issues I could work on
that you think would be more suitable for a newcomer and which wouldn't too
directly interfere with ongoing work; or alternatively, suggestions for
ways i can discover such issues myself...I don't see anything like "low
hanging fruit" in the github issue labels.
For beginners, we label stuff 'easy fix' , but that tends to get
consumed pretty fast. We have over 3k issues, i would just trying
looking through those and find something that affects/interests you,
ping us in irc ansible-devel before starting for guidelines or
evaluation on difficulty.
I would actually recommend code reviewing a few PRs first to get a
good grasp of the underlying systems.