[openstack-dev] Can I count on the OS-TRUST extension for a backup service?
In the implementation of a instance backup service for OpenStack, on restore I need to (re)create the restored instance in the original tenant. Restores can be fired off by an administrator (not the original user), so at instance-create time I have two main choices: 1. Create the instance as the backup service. 2. Create the instance as the original user. Clearly (1) is workable (given the backup user has access to the tenant). Keypairs are a bit of an issue, but solvable. Also clearly (2) is better, but that requires a means to impersonate the original user. Keystone trusts seem to be that means, but raises additional questions. (Also the fact the current documentation for Keystone is incomplete in this area does not raise the confidence level.) 1. How far back is the Keystone OS-TRUST extension reliable? (Kilo? Juno?) 2. Do any OpenStack distributions omit the OS-TRUST extension? A feature labelled as an "extension" poses a risk to the developer. :) Trying to get a handle on that risk. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] cross project communication: Return request-id to caller
On 09:50 Dec 22, Doug Hellmann wrote: > Excerpts from Kekane, Abhishek's message of 2015-12-18 06:27:59 +: > > My point here is, should we follow this new approach in all python-clients > > to maintain the consistency across openstack? > > The original design was discussed, reviewed, and if I understand > correctly is already mostly implemented. Let's not change that. +1 this will just create confusion and more work of what's already out there. I would encourage folks to join us in the cross-project meetings where these specs are discussed [1] before they are rolled out to projects. [1] - https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Third-Party][CI] Add accouts to CI group
Hi Watanabe, Fujitsu ETERNUS FC CI account has been added to the gerrit group. On Thu, Dec 24, 2015 at 10:16 PM, Watanabe, Isao < watanabe_i...@jp.fujitsu.com> wrote: > Hello, Third-Party Coordinators > > Sorry for sending the wrong information. > Please ignore the previous mail. > > Could you add the following account to CI mail list group, please? > Name: Fujitsu ETERNUS FC CI > Mail: lsoft-openstac...@ml.css.fujitsu.com > > Best regards, > Watanabe.isao > > > -Original Message- > > From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com] > > Sent: Friday, December 25, 2015 12:36 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Third-Party][CI] Add accouts to CI group > > > > Hello, Third-Party Coordinators > > > > Could you add the following account to CI mail list group, please? > > Name: Fujitsu C-Fabric CI > > Mail: lsoft-cfabri...@ml.css.fujitsu.com > > > > Best regards, > > Watanabe.isao > > > > > > > > > -Original Message- > > > From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com] > > > Sent: Friday, October 16, 2015 8:52 PM > > > To: openstack-dev@lists.openstack.org > > > Subject: [openstack-dev] [Third-Party][CI] Add accouts to CI group > > > > > > Hello, Third-Party Coordinators > > > Cc：Ramy > > > > > > Could you add the following 2 accounts to CI group, please? > > > Also, we will continually update the wiki. > > > [1] > > > Name: Fujitsu C-Fabric CI > > > Mail: lsoft-cfabri...@ml.css.fujitsu.com > > > Wiki: > > > https://wiki.openstack.org/wiki/ThirdPartySystems/Fujitsu_C-Fabric_CI > > > > > > [2] > > > Name: Fujitsu IRMC CI > > > Mail: lsoft-irm...@ml.css.fujitsu.com > > > Wiki: > https://wiki.openstack.org/wiki/ThirdPartySystems/Fujitsu_IRMC_CI > > > > > > > > > Best regards, > > > Watanabe.isao > > > > > > > > > > > > > > > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Configuring ISC dhclient on guest to acquire ipv6 default gateway
Hi Andrei,
Default gateways for IPv6 is always configured with Router Advertisements (RA),
no matter what addressing mode is used. Please ensure that:
- you have a virtual router connected to your IPv6 subnet, this would provide
RA (and actual router) in your network
- accept_ra is enabled in your guest OS: sysctl -a | grep accept_ra
--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.
> On Dec 23, 2015, at 12:50 AM, Andrei Radulescu-Banu
> wrote:
>
> Hi all,
>
> I’ve been trying for a few days to understand how this should work. My guest
> OS is Linux based, using ISC dhclient. In devstack I have configured an ipv6
> net and subnet:
>
> [stack@localhost images]$ neutron net-show private6
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | availability_zone_hints | |
> | availability_zones| nova |
> | id| 55170162-305e-4d04-a159-2a141f0cd685 |
> | mtu | 0|
> | name | private6 |
> | port_security_enabled | True |
> | provider:network_type | vxlan|
> | provider:physical_network | |
> | provider:segmentation_id | 1063 |
> | router:external | False|
> | shared| False|
> | status| ACTIVE |
> | subnets | 4ea435ac-0ede-4dbc-9096-d97c256cc4d5 |
> | tenant_id | 9ede0af4cbe94caf8222b1dcfaac0754 |
> +---+--+
>
> [stack@localhost images]$ neutron subnet-show private-subnet6
> +---+--+
> | Field | Value|
> +---+--+
> | allocation_pools | {"start": "1:2:3:4::100", "end": "1:2:3:4::200"} |
> | cidr | 1:2:3:4::/64 |
> | dns_nameservers | 1:2:3:4::2 |
> | enable_dhcp | True |
> | gateway_ip| 1:2:3:4::1 |
> | host_routes | |
> | id| 4ea435ac-0ede-4dbc-9096-d97c256cc4d5 |
> | ip_version| 6|
> | ipv6_address_mode | dhcpv6-stateful |
> | ipv6_ra_mode | dhcpv6-stateful |
> | name | private-subnet6 |
> | network_id| 55170162-305e-4d04-a159-2a141f0cd685 |
> | subnetpool_id | |
> | tenant_id | 9ede0af4cbe94caf8222b1dcfaac0754 |
> +---+--+
>
> When running dhclient on the interface, however, I am only able to acquire
> the interface address, but not the interface default gateway. I suppose the
> default gateway should be obtained through dhcp6 rather than neighbor
> discovery, because I set both ipv6_address_mode and ipv6_ra_mode to
> dhcpv6-stateful.
>
> Any ideas?
>
> Thanks,
> Andrei
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [Dragonflow] Support configuration of DB clusters
Hi Li Ma, This approach makes sense to me, i was also thinking about the ability for the user to specify additional arguments and parameters to the DB driver. Feel free to register a bug and work on that. Thanks Gal. On Fri, Dec 25, 2015 at 1:07 PM, Li Ma wrote: > Hi all, currently, we only support db_ip and db_port in the > configuration file. Some DB SDK supports clustering, like Zookeeper. > You can specify a list of nodes when client application starts to > connect to servers. > > I'd like to implement this feature, specifying ['ip1:port', > 'ip2:port', 'ip3:port'] list in the configuration file. If only one > server exists, just set it to ['ip1:port']. > > Any suggestions? > > -- > > Li Ma (Nick) > Email: skywalker.n...@gmail.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best Regards , The G. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] [Dragonflow] Support configuration of DB clusters
Hi all, currently, we only support db_ip and db_port in the configuration file. Some DB SDK supports clustering, like Zookeeper. You can specify a list of nodes when client application starts to connect to servers. I'd like to implement this feature, specifying ['ip1:port', 'ip2:port', 'ip3:port'] list in the configuration file. If only one server exists, just set it to ['ip1:port']. Any suggestions? -- Li Ma (Nick) Email: skywalker.n...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Merge Freeze for cutting stable/8.0 branch
Aleksandra, What are "base packages"? Can we merge to fuel-web? 2015-12-24 18:01 GMT+03:00 Aleksandra Fedorova : > Hi, everyone, > > we merged all versioning patches so now Fuel master is versioned as Fuel > 9.0. > > Merge freeze is lifted. > > Please note: > > * Fuel master is now open but only for changes which are still > compatible with 8.0 base repositories. > > All Base OS and OpenStack packages including those that are Fuel > dependencies are currently copied from 8.0 repo and freezed. Please > don't yet merge Fuel changes which require update in base packages. > > * All bug fixes needs to be merged in master first and then > cherry-picked to stable/8.0 branch > > On Thu, Dec 24, 2015 at 3:40 PM, Roman Vyalov > wrote: > > Aleksandra, > > we dont have problems with inconsistent 9.0 repositories. But we found > the > > problem with process of building our ISO[0]. > > It floating bug, but we found the main problem and solve it today > > > > [0] https://bugs.launchpad.net/fuel/+bug/1529073 > > > > On Thu, Dec 24, 2015 at 5:14 AM, Aleksandra Fedorova > > wrote: > >> > >> Hi, here is the status update: > >> > >> - we created stable/8.0 branch in all repositories; > >> - Fuel CI [1] is updated with 8.0 triggers and jobs, fuel-library > >> tests are working on pre-SCF ISO image still; > >> - 8.0 ISO builds are switched to stable/8.0 branch, see [2] for the > first > >> run; > >> - development focus in Launchpad has been switched to mitaka(9.0) series > >> [3] > >> > >> If you file a bug for 8.0 release, please make sure you explicitly > >> target it to 8.0.x series additionally to the mitaka series which it > >> gets by default. > >> > >> Remaining tasks: > >> > >> due to several issues caused by pre-SCF merge rush, we don't yet > >> have a working ISO for version bumps patches [4] > >> > >> Therefore we are still in Merge Freeze, as we need to stabilize master > >> before moving forward. > >> > >> Latest blocker for the merge - inconsistent 9.0 mirrors. Build team > >> will look into it, and I'll post an update with more information. > >> > >> [1] https://ci.fuel-infra.org > >> [2] > https://ci.fuel-infra.org/view/ISO/job/8.0-community.all/185/console > >> [3] https://launchpad.net/fuel/mitaka > >> [4] https://review.openstack.org/#/q/topic:8.0-scf > >> > >> On Wed, Dec 23, 2015 at 10:48 AM, Aleksandra Fedorova > >> wrote: > >> > Hi Fuelers, > >> > > >> > SCF has been declared [1] and we start creating stable/8.0 branch in > >> > all projects. > >> > > >> > Please don't merge anything both to master and to stable/8.0 until we > >> > verify Infra and CI readiness. > >> > > >> > List of projects affected: > >> > > >> > fuel-main > >> > fuel-agent > >> > fuel-astute > >> > fuel-library > >> > fuel-menu > >> > fuel-ostf > >> > fuel-qa > >> > fuel-upgrade > >> > fuel-web > >> > shotgun > >> > python-fuelclient > >> > network-checker > >> > fuel-nailgun-agent > >> > fuel-mirror > >> > > >> > Use #fuel-infra or #fuel-dev IRC channels for questions. > >> > > >> > [1] > >> > > http://lists.openstack.org/pipermail/openstack-dev/2015-December/082939.html > >> > > >> > -- > >> > Aleksandra Fedorova > >> > Fuel CI Team Lead > >> > bookwar > >> > >> > >> > >> -- > >> Aleksandra Fedorova > >> CI Team Lead > >> bookwar > >> > >> > __ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Aleksandra Fedorova > CI Team Lead > bookwar > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Wipe of the nodes' disks
> When do we use the ssh_erase_nodes? It's used in stop_deployment provision stage [0] and for control reboot [1]. > Is it a fall back mechanism if the mcollective fails? Yes it's like fall back mechanism, but it's used always [2]. > That might have been a side effect of cobbler and we should test if it's > still an issue for IBP. As I can see from the code partition table always is wiped before provision [3]. [0] https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L387-L396 [1] https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L417-L425 [2] https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L202-L208 [3] https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L197 Best regards, Svechnikov Artur On Thu, Dec 24, 2015 at 5:27 PM, Alex Schultz wrote: > On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov > wrote: > > Hi, > > We have faced the issue that nodes' disks are wiped after stop > deployment. > > It occurs due to the logic of nodes removing (this is old logic and it's > not > > actual already as I understand). This logic contains step which calls > > erase_node[0], also there is another method with wipe of disks [1]. > AFAIK it > > was needed for smooth cobbler provision and ensure that nodes will not be > > booted from disk when it shouldn't. Instead of cobbler we use IBP from > > fuel-agent where current partition table is wiped before provision stage. > > And use disks wiping for insurance that nodes will not booted from disk > > doesn't seem good solution. I want to propose not to wipe disks and > simply > > unset bootable flag from node disks. > > > > Please share your thoughts. Perhaps some other components use the fact > that > > disks are wiped after node removing or stop deployment. If it's so, then > > please tell about it. > > > > [0] > > > https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137 > > [1] > > > https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb > > > > I thought the erase_node[0] mcollective action was the process that > cleared a node's disks after their removal from an environment. When > do we use the ssh_erase_nodes? Is it a fall back mechanism if the > mcollective fails? My understanding on the history is based around > needing to have the partitions and data wiped so that the LVM groups > and other partition information does not interfere with the > installation process the next time the node is provisioned. That > might have been a side effect of cobbler and we should test if it's > still an issue for IBP. > > > Thanks, > -Alex > > [0] > https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb > > > Best regards, > > Svechnikov Artur > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
