Hi Anne, I had similar questions... The only resource I found is the python-malangeclient code, which effectively provides a cli tool to exercise the API. [1] describes the entities to operate on ( the first argument) - each class is a possible entity, with the second argument to the cli being one of the methods of the class. [2] has a list of the global options ( user I'd, tenant I'd etc). Not great, but a starting point ;)
[1] https://github.com/openstack/python-melangeclient/blob/master/melange/client/ipam_client.py [2] https://github.com/openstack/python-melangeclient/blob/master/melange/client/cli.py#L45 On Feb 28, 2012, at 2:50 PM, Anne Gentle <a...@openstack.org> wrote: > Hi all - > > I'm not sure how people found these melange policy create commands - > is there a doc plan for Melange commands such as those described here? > I read through the API doc housed on github but wasn't sure how CLI > commands are handled. > > Thanks in advance for some clarity, > > Anne > > > ---------- Forwarded message ---------- > From: Jason Kölker <jkoel...@rackspace.com> > Date: Tue, Feb 28, 2012 at 9:31 AM > Subject: Re: [Openstack] Interaction between nova and melange : ip > fixed not found > To: openst...@lists.launchpad.net > > > On Tue, 2012-02-28 at 11:52 +0100, Jérôme Gallard wrote: >> Hi all, >> >> I use the trunk version of Nova, Quantum (with the OVS plugin) and Melange. >> I created networks, everything seems to be right. >> >> I have two questions : >> - the first VM I boot takes always a wrong IP address (for instance >> 172.16.0.0). However, when I boot a second VM, this one takes a good >> IP (for instance 172.16.0.2). Do you know why this can happened ? > > The default melange policy allows assignment of the network address and > synthesise a gateway address (if it is not specified). It will not hand > out the gateway address. The "fix" is to create an ip policy that > restricts the octect 0. I think the syntax is something like > > `melange policy create -t {tennant} name={block_name} > desc={policy_name}` (This should return the policy_id for the next > command) > > `melange unusable_ip_octet create -t {tennant} policy_id={policy_id} > octect=0` > > `melange ip_block update -t {tennant} id={block_id} > policy_id={policy_id}` > > >> - I have an error regarding an fixed IP not found. Effectively, when I >> check the nova database, the fixed_ip table is empty but as I am using >> quantum and melange and their tables seems to be nicely filled. Do you >> have an idea about this issue ? >> This is a copy/paste of the error: >> 2012-02-28 10:45:53 DEBUG nova.rpc.common [-] received >> {u'_context_roles': [u'admin'], u'_context_request_id': >> u'req-461788a6-3570-4fa9-8620-6705eb69243c', u│·· >> '_context_read_deleted': u'no', u'args': {u'address': u'172.16.0.2'}, >> u'_context_auth_token': None, u'_context_strategy': u'noauth', >> u'_context_is_admin': Tr│·· >> ue, u'_context_project_id': None, u'_context_timestamp': >> u'2012-02-28T09:45:53.484445', u'_context_user_id': None, u'method': >> u'lease_fixed_ip', u'_context_r│·· >> emote_address': None} from (pid=8844) _safe_log >> /usr/local/src/nova/nova/rpc/common.py:144 │·· >> 2012-02-28 10:45:53 DEBUG nova.rpc.common >> [req-461788a6-3570-4fa9-8620-6705eb69243c None None] unpacked context: >> {'request_id': u'req-461788a6-3570-4fa9-8620│·· >> -6705eb69243c', 'user_id': None, 'roles': [u'admin'], 'timestamp': >> '2012-02-28T09:45:53.484445', 'is_admin': True, 'auth_token': None, >> 'project_id': None, 'r│·· >> emote_address': None, 'read_deleted': u'no', 'strategy': u'noauth'} >> from (pid=8844) unpack_context >> /usr/local/src/nova/nova/rpc/amqp.py:187 │·· >> 2012-02-28 10:45:53 DEBUG nova.network.manager >> [req-461788a6-3570-4fa9-8620-6705eb69243c None None] Leased IP >> |172.16.0.2| from (pid=8844) lease_fixed_ip >> /us│··r/local/src/nova/nova/network/manager.py:1186 │·· >> 2012-02-28 10:45:53 ERROR nova.rpc.common [-] Exception during message >> handling │··(nova.rpc.common): TRACE: Traceback (most recent call >> last): │·· >> (nova.rpc.common): TRACE: File "/usr/local/src/nova/nova/rpc/amqp.py", >> line 250, in _process_data │··(nova.rpc.common): TRACE: rval = >> node_func(context=ctxt, **node_args) │··(nova.rpc.common): TRACE: File >> "/usr/local/src/nova/nova/network/manager.py", line 1187, in >> lease_fixed_ip │··(nova.rpc.common): TRACE: fixed_ip = >> self.db.fixed_ip_get_by_address(context, address) │·· >> (nova.rpc.common): TRACE: File "/usr/local/src/nova/nova/db/api.py", >> line 473, in fixed_ip_get_by_address │··(nova.rpc.common): TRACE: >> return IMPL.fixed_ip_get_by_address(context, address) >> │··(nova.rpc.common): TRACE: File >> "/usr/local/src/nova/nova/db/sqlalchemy/api.py", line 119, in wrapper >> │·· >> (nova.rpc.common): TRACE: return f(*args, **kwargs) >> │··(nova.rpc.common): TRACE: File >> "/usr/local/src/nova/nova/db/sqlalchemy/api.py", line 1131, in >> fixed_ip_get_by_address │·· >> (nova.rpc.common): TRACE: raise >> exception.FixedIpNotFoundForAddress(address=address) │·· >> (nova.rpc.common): TRACE: FixedIpNotFoundForAddress: Fixed ip not >> found for address 172.16.0.2. │·· >> (nova.rpc.common): TRACE: > > You need to create your networks through nova-manage, otherwise the nova > tables don't get filled in. The next release we are axing the nova > tables as it was just a crutch to get it "usable". > > Happy Hacking! > > 7-11 > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openst...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
