Re: [Openstack] Annoying warning

[Mārtiņš Jakubovičs]

Thanks for clarification.

Best regards,
Martins

On 2016.02.18. 23:58, Morgan Fainberg wrote:
I think you may have hit an issue with a specific version of auth 
token middleware, where one of the options was incorrectly 
"deprecated" and warns. I'm sure either Steve or I can dig up the 
specific info on that, it might be a minor version bump of 
keystonemiddleware package needed or similar. I am fairly certain that 
is just an erroneous message but would like to confirm before saying 
it's 100% certain you can ignore it and it will stop warning/wont 
break you in the future. At least until your next upgrade (and we'll 
work to check for beyond that), that message can be treated as 
advisory and will not impact your running cloud.


--Morgan

On Thu, Feb 18, 2016 at 1:04 PM, Mārtiņš Jakubovičs 
mailto:martins-li...@hostnet.lv>> wrote:


With experimenting I got at least something more clear...

[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = glance
password = XXX

But now I got really confusing warning message:

WARNING oslo_config.cfg [-] Option "username" from group
"keystone_authtoken" is deprecated. Use option "user-name" from
group "keystone_authtoken".

If I change username to user-name glance auth is not working, and
changing back to username works. Looks like bug...

Best regards,
Martins

On 2016.02.18. 22:01, Steve Martinelli wrote:


Looks like you need to update a few options...

This patch is here: https://review.openstack.org/#/c/280887/ is
trying to update the sample in glance's documentation.

In short, you should be able to remove all those and use:

auth_url = http://controller:35357 
project_domain_id = default
project_name = service
user_domain_id = default
username = glance
password = XXX

stevemar

Inactive hide details for Mārtiņš Jakubovičs ---2016/02/18
02:37:33 PM---Hello, Can someone point how to get away from
thisMārtiņš Jakubovičs ---2016/02/18 02:37:33 PM---Hello, Can
someone point how to get away from this annoying warning in
glance-api?

From: Mārtiņš Jakubovičs 

To: openstack@lists.openstack.org

Date: 2016/02/18 02:37 PM
Subject: [Openstack] Annoying warning





Hello,

Can someone point how to get away from this annoying warning in
glance-api?

2016-02-18 21:17:09.140 22878 WARNING
keystonemiddleware.auth_token [-]
Use of the auth_admin_prefix, auth_host, auth_port, auth_protocol,
identity_uri, admin_token, admin_user, admin_password, and
admin_tenant_name configuration options is deprecated in favor of
auth_plugin and related options and may be removed in a future
release.

OpenStack Liberty, glance host - Ubuntu 14.04.

Keystone auth section in glance-api.conf:

[keystone_authtoken]
auth_uri = http://controller:5000
identity_uri = http://controller:35357/
admin_user = glance
admin_password = XXX
admin_tenant_name = service

Best regards,
Martins

___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org

Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack







___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org

Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack




___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Unable to retrieve volume limit information.

[Wilson Kwok]

Thank for your information, the Cinder.conf no keystone auth ...

auth_uri = http://keystone_ip:5000
auth_url = http://keystone_ip:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = services
username = cinder
password = [cinder password]


2016-02-19 2:08 GMT+08:00 Mohammed Naser :

> I believe you’re running into this issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1272572
>
> On Thu, Feb 18, 2016 at 12:31 PM, Wilson Kwok  wrote:
> > Hello,
> >
> > After fresh installed RDO single node in Ravello System platform, I
> created
> > one m1.tiny instance, but the status is running with Unable to retrieve
> > volume limit information error, can somebody help?
> >
> > Thanks
> >
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] OpenStack RC file from within heat

[Davíð Örn Jóhannsson]

?Is it possible to gain access to OpenStack RC file from within a heat 
template, in order to place it on a host during cloud init?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] OpenStack RC file from within heat

[Pavlo Shchelokovskyy]

Davio,

yes, you could do that, but for local files only from CLI, not Horizon. You
could use a "str_replace" and "get_file" functions.

As an example, here
https://github.com/pshchelo/stackdev/blob/master/templates/autoscaling/asg.yaml#L33-L45
I am dropping a local file through the Nova's user data to the VM.

Though I must stress that passing real user cloud credentials inside VM is
a security risk, VMs by default should be better considered as vulnerable.

Best regards,

On Fri, Feb 19, 2016 at 1:08 PM Davíð Örn Jóhannsson 
wrote:

> ​Is it possible to gain access to OpenStack RC file from within a heat
> template, in order to place it on a host during cloud init?
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] OpenStack RC file from within heat

[Davíð Örn Jóhannsson]

My issue is that I need to be able to get information on the tenant name which 
requires me to have access to the api since it is not exposed with meta-data 
and in order to login to the api I need the RC file which includes the tenant 
name, bit of a chicken and an egg problem.


Putting the RC file in Git or something is not wise and this is a part of an 
automation project and is supposed to be reusable for all OS projects where I 
need to uniquely name resources based on which project/tenant it is run in.


I know that Juno has the project_id meta-data but we are still on kilo



Frá: Pavlo Shchelokovskyy 
Sent: 19. febrúar 2016 11:34
Til: Davíð Örn Jóhannsson; openstack@lists.openstack.org
Efni: Re: [Openstack] OpenStack RC file from within heat

Davio,

yes, you could do that, but for local files only from CLI, not Horizon. You 
could use a "str_replace" and "get_file" functions.

As an example, here 
https://github.com/pshchelo/stackdev/blob/master/templates/autoscaling/asg.yaml#L33-L45
I am dropping a local file through the Nova's user data to the VM.

Though I must stress that passing real user cloud credentials inside VM is a 
security risk, VMs by default should be better considered as vulnerable.

Best regards,

On Fri, Feb 19, 2016 at 1:08 PM Davíð Örn Jóhannsson 
mailto:davi...@siminn.is>> wrote:

?Is it possible to gain access to OpenStack RC file from within a heat 
template, in order to place it on a host during cloud init?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Tenant name from within an instance

[gustavo panizzo (gfa)]

On Thu, Feb 18, 2016 at 04:12:24 +, Davíð Örn Jóhannsson wrote:
> ?I'm using masterless puppet recipes within the project and they instances 
> are spun up with heat templates
i don't have a lot of heat experience but i'm sure it can be done in
nova instance definition, besides if you run heat agent inside the vm
you can do a lot of stuff with it


sorry i don't have examples, i use my own panel to do that stuff

i would suggest you to start playing with nova boot --meta key=value 

> 
> 
> Frá: gustavo panizzo (gfa) 
> Sent: 18. febrúar 2016 15:32
> Til: Davíð Örn Jóhannsson; Mohammed Naser
> Afrit: openstack@lists.openstack.org
> Efni: Re: [Openstack] Tenant name from within an instance
> 
> If you are using automation outside the instance (for example to create the 
> instance) you can pass arbitrary metadata to the instance
> 
> Check nova meta and nova boot --meta
> 
> On February 18, 2016 10:56:57 PM GMT+08:00, "Davíð Örn Jóhannsson" 
>  wrote:
> 
> In order to access the API, I'd already have to know the Tenant name.
> 
> This is for automation purposes where I need to be able to run scripts with 
> unique parameters/name per each tenant.
> 
> 
> 
> Frá: Mohammed Naser 
> Sent: 18. febrúar 2016 14:53
> Til: Davíð Örn Jóhannsson
> Afrit: openstack@lists.openstack.org
> Efni: Re: [Openstack] Tenant name from within an instance
> 
> Hey,
> 
> I don't think there is an alternative, you will need to make an API
> call to get the name.
> 
> The Nova API doesn't know anything about tenant/project names, it only
> works with IDs anyways.
> 
> Mohammed
> 
> On Thu, Feb 18, 2016 at 9:38 AM, Davíð Örn Jóhannsson  
> wrote:
>  I'm currently looking for ways to be able to
> retrieve information on what
>  tenant a given openstack instance lives in from within that instance it
>  self.
> 
> 
>  This information is not available from
>  http://169.254.169.254/latest/meta-data and setting up a nova client to
>  access the api is not the way I want to go.
> 
> 
> 
> 
>  Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>  Post to : openstack@lists.openstack.org
>  Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> 
> 
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] using Pseudo Parameters in heat

[Davíð Örn Jóhannsson]

Does someone have any clue about using Pseudo Parameters in heat, my guess was 
to use it as follows but that resulted in property error The Parameter 
(project_id) was not provided and I have found no useful documentation up to 
this point.


OpenStack Kilo


user_data:
str_replace:
template: |
#!/bin/bash -v
echo '127.0.0.1 $SERVER_NAME' >> /etc/hosts
echo $PROJECT_ID > /etc/project_id
params:
$SERVER_NAME: { get_param: server_name }
$PROJECT_ID: { get_param: 'OS::Project_id' }

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] using Pseudo Parameters in heat

[Davíð Örn Jóhannsson]

?Looks like ResourceTypes are not consistent in Casing it is OS::project_id not 
OS::Project_id


Frá: Davíð Örn Jóhannsson
Sent: 19. febrúar 2016 14:30
Til: openstack@lists.openstack.org
Efni: [Openstack] using Pseudo Parameters in heat


Does someone have any clue about using Pseudo Parameters in heat, my guess was 
to use it as follows but that resulted in property error The Parameter 
(project_id) was not provided and I have found no useful documentation up to 
this point.


OpenStack Kilo


user_data:
str_replace:
template: |
#!/bin/bash -v
echo '127.0.0.1 $SERVER_NAME' >> /etc/hosts
echo $PROJECT_ID > /etc/project_id
params:
$SERVER_NAME: { get_param: server_name }
$PROJECT_ID: { get_param: 'OS::Project_id' }

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] using Pseudo Parameters in heat

[Pavlo Shchelokovskyy]

Hi,
as you mention, this is not a ResourceType (you can not create one) but a
pseudo-parameter (pseudo means it is not provided by user, but is
"understood" from the stack itself), thus they have not to be consistent re
capitalization.

Cheers,

On Fri, Feb 19, 2016 at 5:00 PM Davíð Örn Jóhannsson 
wrote:

> ​Looks like ResourceTypes are not consistent in Casing it is
> OS::project_id not OS::Project_id
> --
> *Frá:* Davíð Örn Jóhannsson
> *Sent:* 19. febrúar 2016 14:30
> *Til:* openstack@lists.openstack.org
> *Efni:* [Openstack] using Pseudo Parameters in heat
>
>
> Does someone have any clue about using Pseudo Parameters in heat, my guess
> was to use it as follows but that resulted in property error The Parameter
> (project_id) was not provided and I have found no useful documentation up
> to this point.
>
>
> OpenStack Kilo
>
>
> user_data:
> str_replace:
> template: |
> #!/bin/bash -v
> echo '127.0.0.1 $SERVER_NAME' >> /etc/hosts
> echo $PROJECT_ID > /etc/project_id
> params:
> $SERVER_NAME: { get_param: server_name }
> $PROJECT_ID: { get_param: 'OS::Project_id' }
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Whole sections of ml2_conf.ini being ignored?

[Matt Kassawara]

Looks like we (docs) never backported those fixes to the Liberty version of
the guide. For some reason, the patch does not merge cleanly so I'm not
sure when I'll get to it.

On Thu, Feb 18, 2016 at 11:08 PM, Matt Kassawara 
wrote:

> In Liberty, the L2 agent configuration moves from ml2_conf.ini to
> openvswitch_agent.ini for OVS and linuxbridge_agent.ini for Linux bridge.
>
> On Thu, Feb 18, 2016 at 10:51 PM, Mark Hayden 
> wrote:
>
>> Hi,
>>
>> I have recently installed a small openstack setup using the Liberty
>> release (from Debian Sid packaging).  I have gotten as far as setting up a
>> controller/network and a compute node with keystone, glance, cinder and
>> nova services, but have gotten stuck trying to set up a DVR configuration
>> of Neutron/openvswitch.
>>
>> I had an early OpenStack setup a few years ago (Essex release) but so
>> much has changed from that "primitive" system with nova-network that I am
>> pretty much a novice, but I am particulatly interested in the DVR setup to
>> eliminate the dependency on a single network node for future expansion.
>> However I have spent a few days not making no progress at all.
>>
>> I have tried to follow the relevant guide at
>> http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html
>> as close as possible but I have not been able to get anything to work.  All
>> my ports come up dead (DOWN state, and tagged 4095 in ovs-vsctl) when I set
>> up the virtual router and I cannot launch any instances as they fail at the
>> network port binding stage.
>>
>> In the nova-compute.log:
>>
>> 2016-02-17 19:01:51.160 2556 ERROR nova.compute.manager [instance:
>> 848c9525-3f48-4747-bbf1-d0d8bf52697b] PortBindingFailed: Binding failed for
>> port bf1cde62-7ac6-47a8-8fb9-85ec524d02bd, please check neutron logs for
>> more information.
>>
>> In neutron-server.log:
>>
>> 2016-02-17 19:01:50.669 3224 ERROR neutron.plugins.ml2.managers
>> [req-e6f1dbbd-d26c-456a-af6a-604c905dc194 b1ce670ebde640b0a0b159f01b18c04e
>> ffbdd9d45cf84de0a204acfd0344ee6b - - -] Failed to bind port
>> bf1cde62-7ac6-47a8-8fb9-85ec524d02bd on host hostserver-0001
>>
>> In neutron-openvswitch-agent.log:
>>
>> 2016-02-17 19:01:56.894 8021 INFO neutron.agent.common.ovs_lib
>> [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] Port
>> bf1cde62-7ac6-47a8-8fb9-85ec524d02bd not present in bridge br-int
>>
>> 2016-02-17 19:01:56.894 8021 INFO
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] port_unbound():
>> net_uuid None not in local_vlan_map
>>
>> I have tried using VXLAN as shown in the guide as well as VLAN but both
>> do the same thing.  However this seems to be more than a problem with the
>> settings in the configuration files.  This was revealed when I turned on
>> debug level logging.
>>
>> For some reason no matter what settings I try in ml2_conf.ini most of
>> them are ignored--it doesn't matter how many services I stop and start or
>> even rebooting the entire system (even completely wiping out the database
>> and starting over with network config), ALL the settings in the [ml2]
>> section and all the [ml2_type_*] sections are ignored and a set of default
>> values are used.  The real sticking point seems to be that
>> mechanism_drivers is always an empty list and tenant_network_types is
>> always just ['local'].  As such nova refuses to start any instances on the
>> networks I set up.
>>
>> Has anybody else seen this behaviour? For what it's worth here is what I
>> currently have in my ml2_conf.ini file:
>>
>>
>>
>> [ml2]
>> type_drivers = flat,vlan,gre,vxlan
>> tenant_network_types = vlan,gre,vxlan
>> mechanism_drivers = openvswitch,l2population
>>
>> [ml2_type_flat]
>> flat_networks = public
>>
>> [ml2_type_vlan]
>> network_vlan_ranges = vlans:3:63
>>
>> [ml2_type_gre]
>> tunnel_id_ranges = 1000:1999
>>
>> [ml2_type_vxlan]
>> vni_ranges = 2000:2999
>> vxlan_group = 239.1.1.1
>>
>> [ovs]
>> local_ip = 10.37.3.254
>> bridge_mappings = public:br-out,vlans:br-ex
>>
>> [agent]
>> l2_population = True
>> tunnel_types = vxlan,gre
>> enable_distributed_routing = True
>> arp_responder = True
>>
>> [securitygroup]
>> firewall_driver =
>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>> enable_security_group = True
>> enable_ipset = True
>>
>> and here is a sample of what appears in my logs:
>>
>> In neutron-server.log
>>
>> 2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-]
>> ml2_type_flat.flat_networks = [] log_opt_values
>> /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233
>> 2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-]
>> ml2.extension_drivers = [] log_opt_values
>> /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233
>> 2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-]
>> ml2.external_network_type = None log_opt_values
>> /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233
>> 2016-02-18 11:37:12.354 13857 DEBUG oslo_service.s

Re: [Openstack] [Keystone] Dynamic RBAC policy please?

[Steve Martinelli]

Hey Bruno,

Dynamic policy is just one aspect of the issues keystone has with
authorization. We've also recently merged `implied roles`, which can be
seen here:
http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html
Additionally, a few keystone core members have proposed this cross-project
spec: https://review.openstack.org/#/c/245629/ - an effort to create a
common policy scenario across all projects.

What I'm trying to convey is that we know there are shortcomings, it's on
our radar and we're trying to solve them. Feedback from operators is
paramount for us to make the right changes, so feel free to review the new
cross-project spec as well!

Steve Martinelli
OpenStack Keystone Project Team Lead



From:   Bruno L 
To: openstack 
Date:   2016/02/18 04:47 PM
Subject:[Openstack] [Keystone] Dynamic RBAC policy please?



Hi everyone,

I thought I'd pass on feedback from a Catalyst Cloud customer showing how
desperate people are for dynamic RBAC.

---

Subject: "kill me now"

"Sometimes Openstack just seems half-baked.  None of the ACL / IAM we need
for an enterprise solution is actually there, so I'm resorting to splitting
things across multiple accounts, but then I run into problems when I want
something like private ..."

---

I don't know how other cloud service providers feel about this topic, but
here in New Zealand we have several customers (in particular large ones)
needing more granular access control. Ultimately customers want to be able
to define their own roles and policies, ideally to a very granular level
(eg: Application X role allows user to perform all actions on compute
instance with ID 1234).

We are aware of the work proposed by Adam Young from RedHat (
https://review.openstack.org/#/c/279379/) and think he is absolutely on the
right track. We are even keen to help with the development work related to
this blueprint.

My main concern here is that such a change requires coordinated effort
across all projects to adopt the new dynamic RBAC mechanism. The key word
here is "coordinated", because from a governance point of view I think
OpenStack is lacking a few mid-cycle meetings where all PTLs and TCs agree
on a handful of cross-project blueprints that are essential to advance
OpenStack and ensure that all project teams working on them.

Keen to hear your thoughts about this matter.

Cheers,
Bruno

Catalyst Cloud
http://www.catalyst.net.nz/catalyst-cloud
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Designate, pdns, mdns, AXFR, mysql

[Andrew Bogott]

I'm running designate kilo with a pdns backend.  I originally set 
things up in Juno, with designate-central syncing directly to the pdns 
mysql backend.  Everything was stable until my upgrade to Kilo.  During 
the upgrade to Kilo I was advised to add the mdns service, which I did, 
and I got things mostly working.  Every once in a while my pdns service 
falls over, though, and the pdns logs are VERY strange.


As best I can tell, I am now (accidentally) using two simultaneous 
pdns backends:  designate-central writes directly to the pdns mysql 
database, but mdns also sends sync requests which causes pdns to grab 
records via AXFR and write them to the database (even though they are 
already there, thanks to the direct writing by central).  As you can 
imagine, this allows for a host of weird race conditions.


The docs for this are baffling -- designate design is changing 
rapidly and most docs are unversioned, so it's hard for me to know what 
I'm looking at.  Here are my questions:


1)  Is it still possible to have central write directly to mysql 
backend?  Can I, in that case, simply turn mdns off, switch my pdns 
service to master=false slave=false and live happily and simply?


2)  If, on the contrary, I'm meant to do this via AXFR, why do the docs 
still tell me to configure designate with access to the pdns mysql backend?


3)  (meta-question) Is there a designate-specific list, or new IRC 
channel I should be using?  I have in the past gotten good support in 
#openstack-designate on freenode, but that channel has been utterly 
silent for several months.


Thanks all!

-Andrew

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Whole sections of ml2_conf.ini being ignored?

[Matt Kassawara]

I managed to do the backport today, so you should see the new version merge
into the Liberty version in the next few days.

On Fri, Feb 19, 2016 at 10:38 AM, Mark Hayden  wrote:

> Thanks for the quick help. I confirmed that the debian packaged install is
> set up this new way and moved the settings to the new location and finally
> made some progress. After clearing out the stuck "binding failed" from the
> database all the ports bind and my VM creates with a NIC and I can assign
> fixed and floating IPs.
>
> Now onto the next challenge: I can ping the virtual router (even from the
> internet on its public port!) but cannot reach the running instance on
> either IP (tried all the namespaces with ip netns exec... with both IPs but
> nothing). But I will create a new thread here unless someone has a quick
> answer.
> On 19 Feb 2016 09:00, Matt Kassawara  wrote:
>
> Looks like we (docs) never backported those fixes to the Liberty version
> of the guide. For some reason, the patch does not merge cleanly so I'm not
> sure when I'll get to it.
>
> On Thu, Feb 18, 2016 at 11:08 PM, Matt Kassawara 
> wrote:
>
> In Liberty, the L2 agent configuration moves from ml2_conf.ini to
> openvswitch_agent.ini for OVS and linuxbridge_agent.ini for Linux bridge.
>
> On Thu, Feb 18, 2016 at 10:51 PM, Mark Hayden 
> wrote:
>
> Hi,
>
> I have recently installed a small openstack setup using the Liberty
> release (from Debian Sid packaging).  I have gotten as far as setting up a
> controller/network and a compute node with keystone, glance, cinder and
> nova services, but have gotten stuck trying to set up a DVR configuration
> of Neutron/openvswitch.
>
> I had an early OpenStack setup a few years ago (Essex release) but so much
> has changed from that "primitive" system with nova-network that I am pretty
> much a novice, but I am particulatly interested in the DVR setup to
> eliminate the dependency on a single network node for future expansion.
> However I have spent a few days not making no progress at all.
>
> I have tried to follow the relevant guide at
> http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html
> as close as possible but I have not been able to get anything to work.  All
> my ports come up dead (DOWN state, and tagged 4095 in ovs-vsctl) when I set
> up the virtual router and I cannot launch any instances as they fail at the
> network port binding stage.
>
> In the nova-compute.log:
>
> 2016-02-17 19:01:51.160 2556 ERROR nova.compute.manager [instance:
> 848c9525-3f48-4747-bbf1-d0d8bf52697b] PortBindingFailed: Binding failed for
> port bf1cde62-7ac6-47a8-8fb9-85ec524d02bd, please check neutron logs for
> more information.
>
> In neutron-server.log:
>
> 2016-02-17 19:01:50.669 3224 ERROR neutron.plugins.ml2.managers
> [req-e6f1dbbd-d26c-456a-af6a-604c905dc194 b1ce670ebde640b0a0b159f01b18c04e
> ffbdd9d45cf84de0a204acfd0344ee6b - - -] Failed to bind port
> bf1cde62-7ac6-47a8-8fb9-85ec524d02bd on host hostserver-0001
>
> In neutron-openvswitch-agent.log:
>
> 2016-02-17 19:01:56.894 8021 INFO neutron.agent.common.ovs_lib
> [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] Port
> bf1cde62-7ac6-47a8-8fb9-85ec524d02bd not present in bridge br-int
>
> 2016-02-17 19:01:56.894 8021 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] port_unbound():
> net_uuid None not in local_vlan_map
>
> I have tried using VXLAN as shown in the guide as well as VLAN but both do
> the same thing.  However this seems to be more than a problem with the
> settings in the configuration files.  This was revealed when I turned on
> debug level logging.
>
> For some reason no matter what settings I try in ml2_conf.ini most of them
> are ignored--it doesn't matter how many services I stop and start or even
> rebooting the entire system (even completely wiping out the database and
> starting over with network config), ALL the settings in the [ml2] section
> and all the [ml2_type_*] sections are ignored and a set of default values
> are used.  The real sticking point seems to be that mechanism_drivers is
> always an empty list and tenant_network_types is always just ['local'].  As
> such nova refuses to start any instances on the networks I set up.
>
> Has anybody else seen this behaviour? For what it's worth here is what I
> currently have in my ml2_conf.ini file:
>
>
>
> [ml2]
> type_drivers = flat,vlan,gre,vxlan
> tenant_network_types = vlan,gre,vxlan
> mechanism_drivers = openvswitch,l2population
>
> [ml2_type_flat]
> flat_networks = public
>
> [ml2_type_vlan]
> network_vlan_ranges = vlans:3:63
>
> [ml2_type_gre]
> tunnel_id_ranges = 1000:1999
>
> [ml2_type_vxlan]
> vni_ranges = 2000:2999
> vxlan_group = 239.1.1.1
>
> [ovs]
> local_ip = 10.37..3.254
> bridge_mappings = public:br-out,vlans:br-ex
>
> [agent]
> l2_population = True
> tunnel_types = vxlan,gre
> enable_distributed_routing = True
> arp_responder = True
>
> [securitygroup]
> firewall_drive

Re: [Openstack] [Keystone] Dynamic RBAC policy please?

[Bruno L]

Hi Steve,

Thank you for highlighting the different aspects of it. I'm aware that this
is a journey with multiple steps along the way.

>From what we can see here in New Zealand, these are the kind of features
that would propel the adoption of OpenStack by larger organisations.

How is the cross project blueprint going? Are you getting traction with all
PTLs?

I wonder if a few mid-cycle meetings between the TC and PTLs would be
useful to facilitate and ensure progress on important cross-project
features like this.

Cheers,
Bruno

Catalyst Cloud
http://www.catalyst.net.nz/catalyst-cloud

Hey Bruno,

Dynamic policy is just one aspect of the issues keystone has with
authorization. We've also recently merged `implied roles`, which can be
seen here:
http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/implied-roles.html
Additionally, a few keystone core members have proposed this cross-project
spec: https://review.openstack.org/#/c/245629/ - an effort to create a
common policy scenario across all projects.

What I'm trying to convey is that we know there are shortcomings, it's on
our radar and we're trying to solve them. Feedback from operators is
paramount for us to make the right changes, so feel free to review the new
cross-project spec as well!

Steve Martinelli
OpenStack Keystone Project Team Lead

[image: Inactive hide details for Bruno L ---2016/02/18 04:47:13 PM---Hi
everyone, I thought I'd pass on feedback from a Catalyst Cloud]Bruno L
---2016/02/18 04:47:13 PM---Hi everyone, I thought I'd pass on feedback
from a Catalyst Cloud customer showing how

From: Bruno L 
To: openstack 
Date: 2016/02/18 04:47 PM
Subject: [Openstack] [Keystone] Dynamic RBAC policy please?
--



Hi everyone,

I thought I'd pass on feedback from a Catalyst Cloud customer showing how
desperate people are for dynamic RBAC.

---

Subject: "kill me now"

"Sometimes Openstack just seems half-baked.  None of the ACL / IAM we need
for an enterprise solution is actually there, so I'm resorting to splitting
things across multiple accounts, but then I run into problems when I want
something like private ..."

---

I don't know how other cloud service providers feel about this topic, but
here in New Zealand we have several customers (in particular large ones)
needing more granular access control. Ultimately customers want to be able
to define their own roles and policies, ideally to a very granular level
(eg: Application X role allows user to perform all actions on compute
instance with ID 1234).

We are aware of the work proposed by Adam Young from RedHat (
*https://review.openstack.org/#/c/279379/*
) and think he is absolutely on
the right track. We are even keen to help with the development work related
to this blueprint.

My main concern here is that such a change requires coordinated effort
across all projects to adopt the new dynamic RBAC mechanism. The key word
here is "coordinated", because from a governance point of view I think
OpenStack is lacking a few mid-cycle meetings where all PTLs and TCs agree
on a handful of cross-project blueprints that are essential to advance
OpenStack and ensure that all project teams working on them.

Keen to hear your thoughts about this matter.

Cheers,
Bruno

Catalyst Cloud
*http://www.catalyst.net.nz/catalyst-cloud*

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here?

[Martinx - ジェームズ]

Guys,

 I want to formalize my protest against Glance V2 usability.

 With Glance V1, you can straight away, add an image based on its remote
URL location, then, Glance will download the image ONLY when someone launch
it.

 This is very cool and I can add, easily and automatically by Ansible, for
example, dozens of images at once, right after deploying OpenStack.

 However, this is much worse now, when with Glance V2, as follows:

-
*** Glance V1 procedure:

 1) Add an image and its remote location at once:

 glance image-create --location
http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
--is-public true --name "Debian 8.3.0 - Jessie - 64-bit - Cloud Based
Image" --container-format bare --disk-format qcow2

 See it? Glance V1 is awesome!

--

*** Glance V2 procedure:

 1) Add an Image WITHOUT a location:

 glance image-create --visibility public --name \"Debian 8.3.0 - Jessie -
64-bit - Cloud Based Image\" --container-format bare --disk-format qcow2

 2) Look (or parse somehow) the stdout, copy to clipboad the Image ID.

 3) Add the location of the image:

 glance location-add --url
http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
$PASTE_IMAGE_ID

 See it? Glance V2 sucks.
-

 It is more complicated now, specially to automate this with Ansible or
other tool! Because there is a need to parser the stdout of step "1" and
store the Image ID somewhere (like a variable), and then, add the remote
location URL for the image.

 Please guys, do something about this!

 NOTE: I will be happy to be wrong here, let me know if I am missing
something.

 I believe that, if the "glance location-add" starts to accept "image name"
(instead of only ID), it will make the automation easier, because the name
is predictable, and the ID is random. Or, if someone tells me how to
auto-generate random IDs for OpenStack, so it will be predictable (I'll be
able to use auto-genarated ID with "image-create", I believe), then, it
will also make the automation easier, I'll be okay with that too!

 Thanks in advance!

Regards,
Thiago
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here?

[Jeremy Hanmer]

You can trivially pre-generate a UUID (via uuidgen or similar) to
create your image with a known UUID if that's sufficient for you.

$UUID=$(uuidgen)
glance image-create --id $UUID ...

On Fri, Feb 19, 2016 at 6:17 PM, Martinx - ジェームズ
 wrote:
> Guys,
>
>  I want to formalize my protest against Glance V2 usability.
>
>  With Glance V1, you can straight away, add an image based on its remote URL
> location, then, Glance will download the image ONLY when someone launch it.
>
>  This is very cool and I can add, easily and automatically by Ansible, for
> example, dozens of images at once, right after deploying OpenStack.
>
>  However, this is much worse now, when with Glance V2, as follows:
>
> -
> *** Glance V1 procedure:
>
>  1) Add an image and its remote location at once:
>
>  glance image-create --location
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> --is-public true --name "Debian 8.3.0 - Jessie - 64-bit - Cloud Based Image"
> --container-format bare --disk-format qcow2
>
>  See it? Glance V1 is awesome!
>
> --
>
> *** Glance V2 procedure:
>
>  1) Add an Image WITHOUT a location:
>
>  glance image-create --visibility public --name \"Debian 8.3.0 - Jessie -
> 64-bit - Cloud Based Image\" --container-format bare --disk-format qcow2
>
>  2) Look (or parse somehow) the stdout, copy to clipboad the Image ID.
>
>  3) Add the location of the image:
>
>  glance location-add --url
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> $PASTE_IMAGE_ID
>
>  See it? Glance V2 sucks.
> -
>
>  It is more complicated now, specially to automate this with Ansible or
> other tool! Because there is a need to parser the stdout of step "1" and
> store the Image ID somewhere (like a variable), and then, add the remote
> location URL for the image.
>
>  Please guys, do something about this!
>
>  NOTE: I will be happy to be wrong here, let me know if I am missing
> something.
>
>  I believe that, if the "glance location-add" starts to accept "image name"
> (instead of only ID), it will make the automation easier, because the name
> is predictable, and the ID is random. Or, if someone tells me how to
> auto-generate random IDs for OpenStack, so it will be predictable (I'll be
> able to use auto-genarated ID with "image-create", I believe), then, it will
> also make the automation easier, I'll be okay with that too!
>
>  Thanks in advance!
>
> Regards,
> Thiago
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here?

[Martinx - ジェームズ]

That would be great!

Sorry for being rude, I'm gonna try to auto-generate the ID from now on...

Thanks!

On 20 February 2016 at 00:53, Mohammed Naser  wrote:

> Hello,
>
> I think you’re being a bit extreme to just use the terms you’ve used
> to describe the API.  A lot of people worked on this to make it ideal,
> and while it’s made life a bit harder, it’s actually made the system
> more robust.  You can fallback to the V1 api if you really can’t
> retrieve the ID.
>
> http://www.gossamer-threads.com/lists/openstack/dev/50406
>
> This can be solved by one simple thing:
>
> glance image-create .. | fgrep ‘| id’ | awk ‘{ print $4 }'
>
>
> If it’s really an issue, you can actually create a image with your own
> UUID.
>
> Thanks,
> Mohammed
>
> On Fri, Feb 19, 2016 at 9:17 PM, Martinx - ジェームズ
>  wrote:
> > Guys,
> >
> >  I want to formalize my protest against Glance V2 usability.
> >
> >  With Glance V1, you can straight away, add an image based on its remote
> URL
> > location, then, Glance will download the image ONLY when someone launch
> it.
> >
> >  This is very cool and I can add, easily and automatically by Ansible,
> for
> > example, dozens of images at once, right after deploying OpenStack.
> >
> >  However, this is much worse now, when with Glance V2, as follows:
> >
> > -
> > *** Glance V1 procedure:
> >
> >  1) Add an image and its remote location at once:
> >
> >  glance image-create --location
> >
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> > --is-public true --name "Debian 8.3.0 - Jessie - 64-bit - Cloud Based
> Image"
> > --container-format bare --disk-format qcow2
> >
> >  See it? Glance V1 is awesome!
> >
> > --
> >
> > *** Glance V2 procedure:
> >
> >  1) Add an Image WITHOUT a location:
> >
> >  glance image-create --visibility public --name \"Debian 8.3.0 - Jessie -
> > 64-bit - Cloud Based Image\" --container-format bare --disk-format qcow2
> >
> >  2) Look (or parse somehow) the stdout, copy to clipboad the Image ID.
> >
> >  3) Add the location of the image:
> >
> >  glance location-add --url
> >
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> > $PASTE_IMAGE_ID
> >
> >  See it? Glance V2 sucks.
> > -
> >
> >  It is more complicated now, specially to automate this with Ansible or
> > other tool! Because there is a need to parser the stdout of step "1" and
> > store the Image ID somewhere (like a variable), and then, add the remote
> > location URL for the image.
> >
> >  Please guys, do something about this!
> >
> >  NOTE: I will be happy to be wrong here, let me know if I am missing
> > something.
> >
> >  I believe that, if the "glance location-add" starts to accept "image
> name"
> > (instead of only ID), it will make the automation easier, because the
> name
> > is predictable, and the ID is random. Or, if someone tells me how to
> > auto-generate random IDs for OpenStack, so it will be predictable (I'll
> be
> > able to use auto-genarated ID with "image-create", I believe), then, it
> will
> > also make the automation easier, I'll be okay with that too!
> >
> >  Thanks in advance!
> >
> > Regards,
> > Thiago
> >
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here?

[Martinx - ジェームズ]

BTW, you're right, OpenStack developers do a GREAT job, it is impressive.

I am just frustrated with new behavior of Glance V2... I still don't like
it, I prefer 1 command, instead of 3.

Again, sorry for choosing bad works, I love OpenStack, this community
always help me and I'm working with it for about 4~5 years, only good
things happening in my life because of this project!

^_^

On 20 February 2016 at 00:59, Martinx - ジェームズ 
wrote:

> That would be great!
>
> Sorry for being rude, I'm gonna try to auto-generate the ID from now on...
>
> Thanks!
>
> On 20 February 2016 at 00:53, Mohammed Naser  wrote:
>
>> Hello,
>>
>> I think you’re being a bit extreme to just use the terms you’ve used
>> to describe the API.  A lot of people worked on this to make it ideal,
>> and while it’s made life a bit harder, it’s actually made the system
>> more robust.  You can fallback to the V1 api if you really can’t
>> retrieve the ID.
>>
>> http://www.gossamer-threads.com/lists/openstack/dev/50406
>>
>> This can be solved by one simple thing:
>>
>> glance image-create .. | fgrep ‘| id’ | awk ‘{ print $4 }'
>>
>>
>> If it’s really an issue, you can actually create a image with your own
>> UUID.
>>
>> Thanks,
>> Mohammed
>>
>> On Fri, Feb 19, 2016 at 9:17 PM, Martinx - ジェームズ
>>  wrote:
>> > Guys,
>> >
>> >  I want to formalize my protest against Glance V2 usability.
>> >
>> >  With Glance V1, you can straight away, add an image based on its
>> remote URL
>> > location, then, Glance will download the image ONLY when someone launch
>> it.
>> >
>> >  This is very cool and I can add, easily and automatically by Ansible,
>> for
>> > example, dozens of images at once, right after deploying OpenStack.
>> >
>> >  However, this is much worse now, when with Glance V2, as follows:
>> >
>> > -
>> > *** Glance V1 procedure:
>> >
>> >  1) Add an image and its remote location at once:
>> >
>> >  glance image-create --location
>> >
>> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
>> > --is-public true --name "Debian 8.3.0 - Jessie - 64-bit - Cloud Based
>> Image"
>> > --container-format bare --disk-format qcow2
>> >
>> >  See it? Glance V1 is awesome!
>> >
>> > --
>> >
>> > *** Glance V2 procedure:
>> >
>> >  1) Add an Image WITHOUT a location:
>> >
>> >  glance image-create --visibility public --name \"Debian 8.3.0 - Jessie
>> -
>> > 64-bit - Cloud Based Image\" --container-format bare --disk-format qcow2
>> >
>> >  2) Look (or parse somehow) the stdout, copy to clipboad the Image ID.
>> >
>> >  3) Add the location of the image:
>> >
>> >  glance location-add --url
>> >
>> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
>> > $PASTE_IMAGE_ID
>> >
>> >  See it? Glance V2 sucks.
>> > -
>> >
>> >  It is more complicated now, specially to automate this with Ansible or
>> > other tool! Because there is a need to parser the stdout of step "1" and
>> > store the Image ID somewhere (like a variable), and then, add the remote
>> > location URL for the image.
>> >
>> >  Please guys, do something about this!
>> >
>> >  NOTE: I will be happy to be wrong here, let me know if I am missing
>> > something.
>> >
>> >  I believe that, if the "glance location-add" starts to accept "image
>> name"
>> > (instead of only ID), it will make the automation easier, because the
>> name
>> > is predictable, and the ID is random. Or, if someone tells me how to
>> > auto-generate random IDs for OpenStack, so it will be predictable (I'll
>> be
>> > able to use auto-genarated ID with "image-create", I believe), then, it
>> will
>> > also make the automation easier, I'll be okay with that too!
>> >
>> >  Thanks in advance!
>> >
>> > Regards,
>> > Thiago
>> >
>> > ___
>> > Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> > Post to : openstack@lists.openstack.org
>> > Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> >
>>
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here?

[Mohammed Naser]

Hello,

I think you’re being a bit extreme to just use the terms you’ve used
to describe the API.  A lot of people worked on this to make it ideal,
and while it’s made life a bit harder, it’s actually made the system
more robust.  You can fallback to the V1 api if you really can’t
retrieve the ID.

http://www.gossamer-threads.com/lists/openstack/dev/50406

This can be solved by one simple thing:

glance image-create .. | fgrep ‘| id’ | awk ‘{ print $4 }'


If it’s really an issue, you can actually create a image with your own UUID.

Thanks,
Mohammed

On Fri, Feb 19, 2016 at 9:17 PM, Martinx - ジェームズ
 wrote:
> Guys,
>
>  I want to formalize my protest against Glance V2 usability.
>
>  With Glance V1, you can straight away, add an image based on its remote URL
> location, then, Glance will download the image ONLY when someone launch it.
>
>  This is very cool and I can add, easily and automatically by Ansible, for
> example, dozens of images at once, right after deploying OpenStack.
>
>  However, this is much worse now, when with Glance V2, as follows:
>
> -
> *** Glance V1 procedure:
>
>  1) Add an image and its remote location at once:
>
>  glance image-create --location
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> --is-public true --name "Debian 8.3.0 - Jessie - 64-bit - Cloud Based Image"
> --container-format bare --disk-format qcow2
>
>  See it? Glance V1 is awesome!
>
> --
>
> *** Glance V2 procedure:
>
>  1) Add an Image WITHOUT a location:
>
>  glance image-create --visibility public --name \"Debian 8.3.0 - Jessie -
> 64-bit - Cloud Based Image\" --container-format bare --disk-format qcow2
>
>  2) Look (or parse somehow) the stdout, copy to clipboad the Image ID.
>
>  3) Add the location of the image:
>
>  glance location-add --url
> http://cdimage.debian.org/cdimage/openstack/8.3.0/debian-8.3.0-openstack-amd64.qcow2
> $PASTE_IMAGE_ID
>
>  See it? Glance V2 sucks.
> -
>
>  It is more complicated now, specially to automate this with Ansible or
> other tool! Because there is a need to parser the stdout of step "1" and
> store the Image ID somewhere (like a variable), and then, add the remote
> location URL for the image.
>
>  Please guys, do something about this!
>
>  NOTE: I will be happy to be wrong here, let me know if I am missing
> something.
>
>  I believe that, if the "glance location-add" starts to accept "image name"
> (instead of only ID), it will make the automation easier, because the name
> is predictable, and the ID is random. Or, if someone tells me how to
> auto-generate random IDs for OpenStack, so it will be predictable (I'll be
> able to use auto-genarated ID with "image-create", I believe), then, it will
> also make the automation easier, I'll be okay with that too!
>
>  Thanks in advance!
>
> Regards,
> Thiago
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Designate, pdns, mdns, AXFR, mysql

[John Belamaric]

> On Feb 19, 2016, at 6:03 PM, Andrew Bogott  wrote:
> 
>I'm running designate kilo with a pdns backend.  I originally set things 
> up in Juno, with designate-central syncing directly to the pdns mysql 
> backend.  Everything was stable until my upgrade to Kilo.  During the upgrade 
> to Kilo I was advised to add the mdns service, which I did, and I got things 
> mostly working.  Every once in a while my pdns service falls over, though, 
> and the pdns logs are VERY strange.
> 
>As best I can tell, I am now (accidentally) using two simultaneous pdns 
> backends:  designate-central writes directly to the pdns mysql database, but 
> mdns also sends sync requests which causes pdns to grab records via AXFR and 
> write them to the database (even though they are already there, thanks to the 
> direct writing by central).  As you can imagine, this allows for a host of 
> weird race conditions.
> 
>The docs for this are baffling -- designate design is changing rapidly and 
> most docs are unversioned, so it's hard for me to know what I'm looking at.  
> Here are my questions:
> 
> 1)  Is it still possible to have central write directly to mysql backend?  
> Can I, in that case, simply turn mdns off, switch my pdns service to 
> master=false slave=false and live happily and simply?
> 
> 2)  If, on the contrary, I'm meant to do this via AXFR, why do the docs still 
> tell me to configure designate with access to the pdns mysql backend?
> 

As I understand it, in Kilo and later mdns must be primary and send data to 
other backends via XFR.

> 3)  (meta-question) Is there a designate-specific list, or new IRC channel I 
> should be using?  I have in the past gotten good support in 
> #openstack-designate on freenode, but that channel has been utterly silent 
> for several months.
> 

Try #openstack-dns instead.


> Thanks all!
> 
> -Andrew
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack