[ansible-project] Re: OpenStack Dynamic Inventory Question
There are two things you should try to help us track down the problem, if you don't mind. First of all: openstack server list (python-openstackclient also uses occ, so that should let us know that the config is working right) If that works and you see the servers, my _hunch_ is that ansible cannot figure out the interface_ip of your server, which means our introspection code is making an assumption. So if you can try making a copy of openstack.py and editing it - find this: if 'interface_ip' not in server: continue and delete it If openstack.py --list _works_ at that point, I'd really love if you'd be kind enough to send me a copy of the output of at least one of the servers so I can see what's going on with your addresses list. (there should be nothing in the output that would be compromosing, but you migth want to scan it - feel free to send the entire output or just one server. OR - if you don't want to do that, I can cook up some more code snippets for you to try to diagnose further. thanks! On Wednesday, March 9, 2016 at 2:27:33 PM UTC-6, Mike Albert wrote: > > Hi, > > I'm trying to configure OpenStack dynamic inventory with Ansible, but I > keep getting the following error: > > mikealbert@rmbp lab (master) $ ./openstack.py --list > Error fetching server list on envvars:Region1: > > I've defined the variables below in my .bash_profile and I've confirmed > that "nova list" returns results > > OS_REGION_NAME > OS_PASSWORD > OS_AUTH_URL > OS_USERNAME > OS_TENANT_NAME > > Not sure if it makes a difference but I'm running Ansible 2.0.1.0. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/ed1849c4-a9eb-4986-a300-778c8d51f502%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Re: os_volume 404 error
Everything Shrews says is correct - I would love an account - and we can
add a metacloud profile to os-client-config too. I'm sure you're not doing
anything too crazy - it turns out that the number of ways all this can
combine are large - we have all sorts of logic already to handle "normal"
behavior. I'm sure we'll just find another nugger of normal :)
On Sunday, September 20, 2015 at 7:32:22 PM UTC-4, David Shrewsbury wrote:
>
> Accounts would be most helpful and appreciated. Myself and Monty Taylor do
> most of the Ansible and
> shade development, so if we could both get access, that would go a long
> way to improving the modules
> for you. Please email me off-list to let me know what you need from us to
> make that happen.
>
> -Dave
>
>
> On Friday, September 18, 2015 at 5:26:44 PM UTC-4, vallard wrote:
>>
>> Ah, thanks for the info on the security group stuff. I'll try that out.
>> I'm happy to let someone have a metacloud account to test things with.
>>
>> On Fri, Sep 18, 2015 at 10:23 AM, David Shrewsbury
>> wrote:
>>
>>> Sorry you're having issues. Sounds like metacloud is doing something we
>>> don't expect with
>>> their endpoints since you are having the same problem. This is difficult
>>> to debug without a
>>> metacloud account.
>>>
>>> Your solution to the image service problem was to add code to remove the
>>> "/v1". Does that
>>> solution also fix the problem with the volume service?
>>>
>>> As for security groups, in your clouds.yaml (which I assume you are
>>> using?), you will need
>>> to set 'secgroup_source' to 'nova'. It defaults to using neutron.
>>>
>>> -Dave
>>>
>>>
>>> On Friday, September 18, 2015 at 9:51:24 AM UTC-4, vallard wrote:
>>>>
>>>> Having the same problem with os_volume that I had with glance images
>>>> where I get a 404 error.
>>>>
>>>> - Ansible 2.0 playbook:
>>>>
>>>> - name: ensure there is a volume for storing data.
>>>> os_volume:
>>>> size: 40
>>>> display_name: lab_volume
>>>> register: vol
>>>>
>>>> Error message:
>>>> fatal: [localhost]: FAILED! => {"changed": false, "failed": true,
>>>> "msg": "Error fetching volume list: Not Found (HTTP 404)"}
>>>>
>>>> When I got an error like this with glance, I had to go in and modify
>>>> some code in the shade library. I made sure I put the shade library back
>>>> to what it was before so it shouldn't be the issue here.
>>>>
>>>> My OpenStack (metacloud) uses v1 APIs of cinder.
>>>>
>>>> The other issue, somewhat related is using the security_groups found in
>>>> 2.0. Those don't work with my openstack environment either because they
>>>> require neutron. No neutron in my environment.
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Ansible Project" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/ansible-project/FwZthkNjlWA/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> ansible-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ansible-project/b1f2f593-bf38-4979-809c-f3d3d33fa9c6%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/ansible-project/b1f2f593-bf38-4979-809c-f3d3d33fa9c6%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Vallard
>> http://benincosa.com
>>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/870fddfb-bdc9-4eb2-8115-d34330664c94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Re: Ansible 2.0 os_server 404 image not found
Sorry for your troubles. The problem is almost certianly in the v1/v2 version detection. I think we can do better for you here. However, in the mean time - would you mind trying something to test a hypothesis? Make a ~/.config/openstack/clouds.yaml with: clouds: metacloud: auth: username: your-user password: your-password project_name: your-project-name auth_url: your-auth-url image_api_version: '1' And then put "cloud: metacloud" in your playbook and see if it works? Figuring out v1 vs. v2 in glance is _hard_ and complex and very prone to breaking, which is why it's one of the tings we put in known-cloud profiles in os-client-config. Now - if that works, awesome. It still sucks as a user experience for you - so I think we need to make sure we can plumb api version overrides through sanely in playbooks. Also - I'm going to go poke the metacloud folks about getting me a metacloud so that I can add a metacloud profile to occ. Also - I'll see if I can reproduce and find another workaround/detection in case all of the above don't work. On Friday, September 4, 2015 at 12:10:39 PM UTC-4, V Benincosa wrote: > > I've done some more debugging on this and it looks like shade is putting > an extra v1 in the URL so it looks like: > > http://some.client.metacloud.net:9292/v1/v1/images/detail?limit=20 > > I ended up changing the glanceclient/v1/images.py by removing all the v1s. > This solved the ansible problem, but now the command line doesn't work > even though ansible does (e.g: glance image-list doesn't work). I'll start > digging into the shade implementation to see where this extra v1 is being > added. Would love any help. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b8dfacbf-970a-4ddd-8a0f-9f17dbd70b02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ansible-project] Re: os_server module
Yeah - if you're v3 passing in domain is important. When you add
user_domain_id and project_domain_id - what error do you get? (you have to
pass in both)
On Friday, August 28, 2015 at 12:19:16 AM UTC-7, Antoine Voiry wrote:
>
> All,
> I am facing something strange with the OS_SERVER module.
> Also I was not able to specify the domain in auth.
> Below is the code snipet
> - os_server:
> state: present
> auth:
> auth_url: https:///v3.0/
> username:
> password:
> project_name:
> name: test_instance
> availability_zone: AZ0
> image: "Ubuntu 14.04 trusty 64"
> key_name: workstation
> timeout: 200
> flavor: m1.medium
> security_groups: default
> validate_certs: no
> auto_floating_ip: yes
>
>
> fatal: [localhost]: FAILED! => {"changed": false, "extra_data": null,
> "failed":true, "msg": "Error fetching server list: Error getting compute
> endpoint: The resource could not be found. (HTTP 404)"}
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/9e6ab74d-46af-49d1-8db4-c7ead8019803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Re: Changing quantum_* plugins to neutron_*
Hesitantly opening old can of worms ...
First of all - I couldn't possibly agree more, renaming things is pretty
awful and painful for users. I also don't believe anything has changed
this this topic was discussed six months ago regarding usage. There are
still folks out there using folsom/quantum - and in fact, given the
continued meteoric rise of ansible, there are almost certainly more people
out there with playbooks that reference quantum_ that would be broken by a
name change than there were six month ago. But herein lies the ultimate
problem - in order to avoid breaking people, which is exactly the right
choice, there continue to be an increasing number of new users of a legacy
name.
To be clear and upfront - I don't care specifically about the
neutron/quantum naming thing itself - if I have to write things that say
quantum, ok - no big deal - I'm more interested in thinking about the
general upgrade/rename problem of which this is just a conveniently
specific example. I'm opening my stupid mouth mainly because I'm starting
to look in to re-writing a chunk of our cloud management infrastructure
with ansible, because you guys have done a really great job - and I'm
concerned about incurring some new technical debt. That is - if I start
writing a bunch of roles and playbooks that reference quantum_ now, and at
some point in the future we may rename them, I'm putting myself in a known
hole. In fact, really, there's never going to be a good time to do that -
it's always going to suck for someone.
SO - and please tell me if I'm on crack here - would you be open to adding
a general ansible feature similar to aliases but for module names? That
way we could more gracefully handle renames that come up allowing people a
transition period.
Looking at the code, there does not seem to be a good way to implement
this in a perfect clean and efficient manner. The ideas I've come up with
so far are:
- symlinks. Kinda gross a little bit, but would work with no code changes.
Breaks on Windows. So no.
- Putting a declarative thing that's always read in each module file.
Even grosser, since it would require actually reading files to find the
file to load - super slow and clunky. No.
- Putting an optional declarative thing that can be searched for on module
load failures. This would put the cost on anyone using an alias.
Additionally, one could put this behind a config option that defaults to
off - but now I've just described a baroque system that's really hard to
reason about.
I hate all of those - but just including them for completeness.
- A global extensible alias registry. The one in the tree could simply be
a dict in lib/ansible/utils/plugins.py that can do a quick mapping at the
top of PluginLoader.find_plugin. Like:
_global_aliases = {
'neutron_network': 'quantum_network',
}
# snip
def find_plugin(self, name):
''' Find a plugin named name '''
if name in _global_aliases:
name = _global_aliases[name]
That would allow the core team the ability to manage a rename over time.
Additionally, one could add a configuration option that could point to a
site yaml file that would allow installations to define aliases - but I
actually personally don't like that - because it has the possibility to
just introduce a bunch of not-very-useful divergence in people's playbooks.
I know that people suggesting things without code are as bad as people
writing code without talking to people. So I figured I just do both
simultaneously and either be twice or half as bad. ) I've cooked up two
pull requests - one that just adds the mechanism and a mapping of neutron
to quantum, and another one which includes the first but also renames the
modules, changes the alias order and updates the docs.
https://github.com/ansible/ansible/pull/7784
https://github.com/ansible/ansible/pull/7785
If either of these are interesting, then awesome. If they're not -
certainly no worries, it's been a fun morning of poking anyway.
Thanks!
Monty
On Thursday, December 5, 2013 12:46:18 PM UTC-8, Michael DeHaan wrote:
>
> We will not be renaming modules for this,
> There may be some grouping in a subcategory in
> The future.
>
> -- Michael
>
> On Dec 5, 2013, at 1:00 PM, Bob Tiernay >
> wrote:
>
> Why not rename all plugins to os_* or openstack_*, including those of
> keystone_*, nova_*? This avoids any future renames as well. I think it
> might also aid newcomers like myself that use OpenStack, but aren't
> familiar with the underlying components.
>
> Cheers,
>
> Bob
>
> On Tuesday, 29 October 2013 21:53:26 UTC-4, Michael DeHaan wrote:
>>
>> It's deprecated in a future release that not everyone is running.
>>
>> We are going to leave this named Quantum and I'm fine with a try/except
>> here.
>>
>> It's easy, it keeps everything working, it avoids bloating the module
>> space.
>>
>> "a few weeks in the repository..."
>>
>> People w
