[Openstack] Unable Upload Image

[Bjorn Mork]

Hi Team,

I need support on my installation, unable to upload images in my setup, It
is showing error "*Error: *Unable to retrieve the images." via GUI,
although on cli , if use the command like shown below it works fine and
shows there is already one image. But unable to show via GUI...


[root@Controller ~]# source /etc/openstack-scripts/admin-openrc
[root@Controller ~]#
[root@Controller ~]# glance image-list
+--++
| ID   | Name   |
+--++
| ade9e725-21bc-4032-90f7-68d517f6106a | cirros |
+--++
[root@Controller ~]#


You are requested to please help me. Thanks

Regards,
B~Mork
___
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] VM start up with no route rules

[Mohammed Naser]

Yup. All of them should be active. If only one is active you don't have HA

Sent from my iPhone

> On Jan 21, 2017, at 10:53 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
>  wrote:
> 
> So based on this, as long as one of dhcp agents is Active, DHCP should be 
> working.
>  
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819
>  
> From: Mohammed Naser [mailto:mna...@vexxhost.com] 
> Sent: Sunday, January 22, 2017 11:47
> To: John Petrini 
> Cc: Xu, Rongjie (Nokia - CN/Hangzhou) ; 
> openstack@lists.openstack.org
> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>  
> DHCP is provided with HA with a simple race. N agents respond to DHCP 
> requests, the one with the fastest answer wins. 
> 
> Sent from my iPhone
> 
> On Jan 21, 2017, at 9:49 PM, John Petrini  wrote:
> 
> In my environment they are both Status = Active Admin = Up
> 
> ___
> 
> John Petrini
> 
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission,  dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
> 
>  
> On Sat, Jan 21, 2017 at 9:31 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
>  wrote:
> OK.
>  
> But how about the status? Per my understanding, one of them should be 
> “STATUS=ACTIVE, ADMIN STATUS=UP” and the other should be “STATUS=DOWN, ADMIN 
> STATUS=UP”. Otherwise, it should be wrong. Right?
>  
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819
>  
> From: John Petrini [mailto:jpetr...@coredial.com] 
> Sent: Sunday, January 22, 2017 10:19
> To: Xu, Rongjie (Nokia - CN/Hangzhou) 
> Cc: Eugen Block ; openstack@lists.openstack.org
> 
> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>  
> Multiple DHCP ports in not uncommon in HA configurations. You can check if 
> this is enabled in /etc/neutron/neutron.conf.
>  
> dhcp_agents_per_network = 2
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission,  dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
> 
>  
> On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
>  wrote:
> Hi,
> 
> Thanks for your analysis. Finally, I found there are two DHCP ports when I 
> create a tenant network with DHCP enabled. That makes VM cannot start up due 
> to fail to get its ip address.
> 
> But why there two DHCP ports when I create the network is still under 
> investigation. Do you have some hints for this? Thanks.
> 
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819
> 
> -Original Message-
> From: Eugen Block [mailto:ebl...@nde.ag]
> Sent: Thursday, January 19, 2017 23:57
> To: openstack@lists.openstack.org
> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
> 
> Does your VM's interface also have DHCP enabled? If it's configured to
> have a static address, it won't be changed by dhcp. Have you used the
> image outside of heat and did it work with dhcp for a single VM?
> 
> 
> Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :
> 
> > Hi,
> >
> > I am launch a heat stack on top of Mirantis OpenStack Mitaka.
> > However, I see no route rules (output of command 'ip route' is
> > empty) inside VM, which make the VM cannot get the metadata from
> > metadata server. Basically, the VM is connected to a management
> > network (192.168.1.0/24 DHCP enabled).
> >
> > How can I debug this problem? Is it something wrong with Neutron? Thanks.
> >
> >
> >
> > Best Regards
> > Xu Rongjie (Max)
> > Mobile:18658176819
> 
> 
> 
> --
> Eugen Block voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg e-mail  : ebl...@nde.ag
> 
>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>Sitz und Registergericht: Hamburg, HRB 90934
>Vorstand: Jens-U. Mozdzen
> USt-IdNr. DE 814 013 983
> 
> 
> ___
> 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] VM start up with no route rules

[Xu, Rongjie (Nokia - CN/Hangzhou)]

So based on this, as long as one of dhcp agents is Active, DHCP should be 
working.

Best Regards
Xu Rongjie (Max)
Mobile:18658176819

From: Mohammed Naser [mailto:mna...@vexxhost.com]
Sent: Sunday, January 22, 2017 11:47
To: John Petrini 
Cc: Xu, Rongjie (Nokia - CN/Hangzhou) ; 
openstack@lists.openstack.org
Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

DHCP is provided with HA with a simple race. N agents respond to DHCP requests, 
the one with the fastest answer wins.

Sent from my iPhone

On Jan 21, 2017, at 9:49 PM, John Petrini 
> wrote:
In my environment they are both Status = Active Admin = Up


___

John Petrini

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission,  dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

On Sat, Jan 21, 2017 at 9:31 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
> wrote:
OK.

But how about the status? Per my understanding, one of them should be 
“STATUS=ACTIVE, ADMIN STATUS=UP” and the other should be “STATUS=DOWN, ADMIN 
STATUS=UP”. Otherwise, it should be wrong. Right?

Best Regards
Xu Rongjie (Max)
Mobile:18658176819

From: John Petrini [mailto:jpetr...@coredial.com]
Sent: Sunday, January 22, 2017 10:19
To: Xu, Rongjie (Nokia - CN/Hangzhou) 
>
Cc: Eugen Block >; 
openstack@lists.openstack.org

Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

Multiple DHCP ports in not uncommon in HA configurations. You can check if this 
is enabled in /etc/neutron/neutron.conf.

dhcp_agents_per_network = 2

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission,  dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
> wrote:
Hi,

Thanks for your analysis. Finally, I found there are two DHCP ports when I 
create a tenant network with DHCP enabled. That makes VM cannot start up due to 
fail to get its ip address.

But why there two DHCP ports when I create the network is still under 
investigation. Do you have some hints for this? Thanks.

Best Regards
Xu Rongjie (Max)
Mobile:18658176819
-Original Message-
From: Eugen Block [mailto:ebl...@nde.ag]
Sent: Thursday, January 19, 2017 23:57
To: openstack@lists.openstack.org
Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

Does your VM's interface also have DHCP enabled? If it's configured to
have a static address, it won't be changed by dhcp. Have you used the
image outside of heat and did it work with dhcp for a single VM?


Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" 
>:

> Hi,
>
> I am launch a heat stack on top of Mirantis OpenStack Mitaka.
> However, I see no route rules (output of command 'ip route' is
> empty) inside VM, which make the VM cannot get the metadata from
> metadata server. Basically, the VM is connected to a management
> network (192.168.1.0/24 DHCP enabled).
>
> How can I debug this problem? Is it something wrong with Neutron? Thanks.
>
>
>
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819



--
Eugen Block voice   : +49-40-559 51 
75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 
77
Postfach 61 03 15
D-22423 Hamburg e-mail  : 
ebl...@nde.ag

 Vorsitzende des Aufsichtsrates: Angelika Mozdzen
   Sitz und Registergericht: Hamburg, HRB 90934
   Vorstand: Jens-U. Mozdzen
USt-IdNr. DE 814 013 983


___
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] VM start up with no route rules

[Mohammed Naser]

DHCP is provided with HA with a simple race. N agents respond to DHCP requests, 
the one with the fastest answer wins. 

Sent from my iPhone

> On Jan 21, 2017, at 9:49 PM, John Petrini  wrote:
> 
> In my environment they are both Status = Active Admin = Up
> 
> ___
> 
> John Petrini
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential and/or privileged 
> material. Any review, retransmission,  dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
> 
> 
>> On Sat, Jan 21, 2017 at 9:31 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
>>  wrote:
>> OK.
>> 
>>  
>> 
>> But how about the status? Per my understanding, one of them should be 
>> “STATUS=ACTIVE, ADMIN STATUS=UP” and the other should be “STATUS=DOWN, ADMIN 
>> STATUS=UP”. Otherwise, it should be wrong. Right?
>> 
>>  
>> 
>> Best Regards
>> 
>> Xu Rongjie (Max)
>> 
>> Mobile:18658176819
>> 
>>  
>> 
>> From: John Petrini [mailto:jpetr...@coredial.com] 
>> Sent: Sunday, January 22, 2017 10:19
>> To: Xu, Rongjie (Nokia - CN/Hangzhou) 
>> Cc: Eugen Block ; openstack@lists.openstack.org
>> 
>> 
>> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>>  
>> 
>> Multiple DHCP ports in not uncommon in HA configurations. You can check if 
>> this is enabled in /etc/neutron/neutron.conf.
>> 
>>  
>> 
>> dhcp_agents_per_network = 2
>> 
>> The information transmitted is intended only for the person or entity to 
>> which it is addressed and may contain confidential and/or privileged 
>> material. Any review, retransmission,  dissemination or other use of, or 
>> taking of any action in reliance upon, this information by persons or 
>> entities other than the intended recipient is prohibited. If you received 
>> this in error, please contact the sender and delete the material from any 
>> computer.
>> 
>>  
>> 
>> On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
>>  wrote:
>> 
>> Hi,
>> 
>> Thanks for your analysis. Finally, I found there are two DHCP ports when I 
>> create a tenant network with DHCP enabled. That makes VM cannot start up due 
>> to fail to get its ip address.
>> 
>> But why there two DHCP ports when I create the network is still under 
>> investigation. Do you have some hints for this? Thanks.
>> 
>> Best Regards
>> Xu Rongjie (Max)
>> Mobile:18658176819
>> 
>> 
>> -Original Message-
>> From: Eugen Block [mailto:ebl...@nde.ag]
>> Sent: Thursday, January 19, 2017 23:57
>> To: openstack@lists.openstack.org
>> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>> 
>> Does your VM's interface also have DHCP enabled? If it's configured to
>> have a static address, it won't be changed by dhcp. Have you used the
>> image outside of heat and did it work with dhcp for a single VM?
>> 
>> 
>> Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :
>> 
>> > Hi,
>> >
>> > I am launch a heat stack on top of Mirantis OpenStack Mitaka.
>> > However, I see no route rules (output of command 'ip route' is
>> > empty) inside VM, which make the VM cannot get the metadata from
>> > metadata server. Basically, the VM is connected to a management
>> > network (192.168.1.0/24 DHCP enabled).
>> >
>> > How can I debug this problem? Is it something wrong with Neutron? Thanks.
>> >
>> >
>> >
>> > Best Regards
>> > Xu Rongjie (Max)
>> > Mobile:18658176819
>> 
>> 
>> 
>> --
>> Eugen Block voice   : +49-40-559 51 75
>> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
>> Postfach 61 03 15
>> D-22423 Hamburg e-mail  : ebl...@nde.ag
>> 
>>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>>Sitz und Registergericht: Hamburg, HRB 90934
>>Vorstand: Jens-U. Mozdzen
>> USt-IdNr. DE 814 013 983
>> 
>> 
>> ___
>> 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] [OpenStack] VM start up with no route rules

[John Petrini]

In my environment they are both Status = Active Admin = Up

___

John Petrini

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Sat, Jan 21, 2017 at 9:31 PM, Xu, Rongjie (Nokia - CN/Hangzhou) <
rongjie...@nokia.com> wrote:

> OK.
>
>
>
> But how about the status? Per my understanding, one of them should be
> “STATUS=ACTIVE, ADMIN STATUS=UP” and the other should be “STATUS=DOWN,
> ADMIN STATUS=UP”. Otherwise, it should be wrong. Right?
>
>
>
> Best Regards
>
> Xu Rongjie (Max)
>
> Mobile:18658176819 <(865)%20817-6819>
>
>
>
> *From:* John Petrini [mailto:jpetr...@coredial.com]
> *Sent:* Sunday, January 22, 2017 10:19
> *To:* Xu, Rongjie (Nokia - CN/Hangzhou) 
> *Cc:* Eugen Block ; openstack@lists.openstack.org
>
> *Subject:* Re: [Openstack] [OpenStack] VM start up with no route rules
>
>
>
> Multiple DHCP ports in not uncommon in HA configurations. You can check if
> this is enabled in /etc/neutron/neutron.conf.
>
>
>
> dhcp_agents_per_network = 2
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission,  dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
>
>
> On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) <
> rongjie...@nokia.com> wrote:
>
> Hi,
>
> Thanks for your analysis. Finally, I found there are two DHCP ports when I
> create a tenant network with DHCP enabled. That makes VM cannot start up
> due to fail to get its ip address.
>
> But why there two DHCP ports when I create the network is still under
> investigation. Do you have some hints for this? Thanks.
>
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819
>
> -Original Message-
> From: Eugen Block [mailto:ebl...@nde.ag]
> Sent: Thursday, January 19, 2017 23:57
> To: openstack@lists.openstack.org
> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>
> Does your VM's interface also have DHCP enabled? If it's configured to
> have a static address, it won't be changed by dhcp. Have you used the
> image outside of heat and did it work with dhcp for a single VM?
>
>
> Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :
>
> > Hi,
> >
> > I am launch a heat stack on top of Mirantis OpenStack Mitaka.
> > However, I see no route rules (output of command 'ip route' is
> > empty) inside VM, which make the VM cannot get the metadata from
> > metadata server. Basically, the VM is connected to a management
> > network (192.168.1.0/24 DHCP enabled).
> >
> > How can I debug this problem? Is it something wrong with Neutron? Thanks.
> >
> >
> >
> > Best Regards
> > Xu Rongjie (Max)
> > Mobile:18658176819
>
>
>
> --
> Eugen Block voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg e-mail  : ebl...@nde.ag
>
>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>Sitz und Registergericht: Hamburg, HRB 90934
>Vorstand: Jens-U. Mozdzen
> USt-IdNr. DE 814 013 983
>
>
> ___
> 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] [OpenStack] VM start up with no route rules

[Xu, Rongjie (Nokia - CN/Hangzhou)]

OK.

But how about the status? Per my understanding, one of them should be 
“STATUS=ACTIVE, ADMIN STATUS=UP” and the other should be “STATUS=DOWN, ADMIN 
STATUS=UP”. Otherwise, it should be wrong. Right?

Best Regards
Xu Rongjie (Max)
Mobile:18658176819

From: John Petrini [mailto:jpetr...@coredial.com]
Sent: Sunday, January 22, 2017 10:19
To: Xu, Rongjie (Nokia - CN/Hangzhou) 
Cc: Eugen Block ; openstack@lists.openstack.org
Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

Multiple DHCP ports in not uncommon in HA configurations. You can check if this 
is enabled in /etc/neutron/neutron.conf.

dhcp_agents_per_network = 2

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission,  dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) 
> wrote:
Hi,

Thanks for your analysis. Finally, I found there are two DHCP ports when I 
create a tenant network with DHCP enabled. That makes VM cannot start up due to 
fail to get its ip address.

But why there two DHCP ports when I create the network is still under 
investigation. Do you have some hints for this? Thanks.

Best Regards
Xu Rongjie (Max)
Mobile:18658176819

-Original Message-
From: Eugen Block [mailto:ebl...@nde.ag]
Sent: Thursday, January 19, 2017 23:57
To: openstack@lists.openstack.org
Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

Does your VM's interface also have DHCP enabled? If it's configured to
have a static address, it won't be changed by dhcp. Have you used the
image outside of heat and did it work with dhcp for a single VM?


Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" 
>:

> Hi,
>
> I am launch a heat stack on top of Mirantis OpenStack Mitaka.
> However, I see no route rules (output of command 'ip route' is
> empty) inside VM, which make the VM cannot get the metadata from
> metadata server. Basically, the VM is connected to a management
> network (192.168.1.0/24 DHCP enabled).
>
> How can I debug this problem? Is it something wrong with Neutron? Thanks.
>
>
>
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819



--
Eugen Block voice   : +49-40-559 51 
75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 
77
Postfach 61 03 15
D-22423 Hamburg e-mail  : 
ebl...@nde.ag

 Vorsitzende des Aufsichtsrates: Angelika Mozdzen
   Sitz und Registergericht: Hamburg, HRB 90934
   Vorstand: Jens-U. Mozdzen
USt-IdNr. DE 814 013 983


___
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] [OpenStack] VM start up with no route rules

[John Petrini]

Multiple DHCP ports in not uncommon in HA configurations. You can check if
this is enabled in /etc/neutron/neutron.conf.

dhcp_agents_per_network = 2

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Sat, Jan 21, 2017 at 8:13 PM, Xu, Rongjie (Nokia - CN/Hangzhou) <
rongjie...@nokia.com> wrote:

> Hi,
>
> Thanks for your analysis. Finally, I found there are two DHCP ports when I
> create a tenant network with DHCP enabled. That makes VM cannot start up
> due to fail to get its ip address.
>
> But why there two DHCP ports when I create the network is still under
> investigation. Do you have some hints for this? Thanks.
>
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819
>
>
> -Original Message-
> From: Eugen Block [mailto:ebl...@nde.ag]
> Sent: Thursday, January 19, 2017 23:57
> To: openstack@lists.openstack.org
> Subject: Re: [Openstack] [OpenStack] VM start up with no route rules
>
> Does your VM's interface also have DHCP enabled? If it's configured to
> have a static address, it won't be changed by dhcp. Have you used the
> image outside of heat and did it work with dhcp for a single VM?
>
>
> Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :
>
> > Hi,
> >
> > I am launch a heat stack on top of Mirantis OpenStack Mitaka.
> > However, I see no route rules (output of command 'ip route' is
> > empty) inside VM, which make the VM cannot get the metadata from
> > metadata server. Basically, the VM is connected to a management
> > network (192.168.1.0/24 DHCP enabled).
> >
> > How can I debug this problem? Is it something wrong with Neutron? Thanks.
> >
> >
> >
> > Best Regards
> > Xu Rongjie (Max)
> > Mobile:18658176819
>
>
>
> --
> Eugen Block voice   : +49-40-559 51 75
> NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
> Postfach 61 03 15
> D-22423 Hamburg e-mail  : ebl...@nde.ag
>
>  Vorsitzende des Aufsichtsrates: Angelika Mozdzen
>Sitz und Registergericht: Hamburg, HRB 90934
>Vorstand: Jens-U. Mozdzen
> USt-IdNr. DE 814 013 983
>
>
> ___
> 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] [OpenStack] VM start up with no route rules

[Xu, Rongjie (Nokia - CN/Hangzhou)]

Hi,

Thanks for your analysis. Finally, I found there are two DHCP ports when I 
create a tenant network with DHCP enabled. That makes VM cannot start up due to 
fail to get its ip address. 

But why there two DHCP ports when I create the network is still under 
investigation. Do you have some hints for this? Thanks.

Best Regards
Xu Rongjie (Max)
Mobile:18658176819


-Original Message-
From: Eugen Block [mailto:ebl...@nde.ag] 
Sent: Thursday, January 19, 2017 23:57
To: openstack@lists.openstack.org
Subject: Re: [Openstack] [OpenStack] VM start up with no route rules

Does your VM's interface also have DHCP enabled? If it's configured to  
have a static address, it won't be changed by dhcp. Have you used the  
image outside of heat and did it work with dhcp for a single VM?


Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :

> Hi,
>
> I am launch a heat stack on top of Mirantis OpenStack Mitaka.  
> However, I see no route rules (output of command 'ip route' is  
> empty) inside VM, which make the VM cannot get the metadata from  
> metadata server. Basically, the VM is connected to a management  
> network (192.168.1.0/24 DHCP enabled).
>
> How can I debug this problem? Is it something wrong with Neutron? Thanks.
>
>
>
> Best Regards
> Xu Rongjie (Max)
> Mobile:18658176819



-- 
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

 Vorsitzende des Aufsichtsrates: Angelika Mozdzen
   Sitz und Registergericht: Hamburg, HRB 90934
   Vorstand: Jens-U. Mozdzen
USt-IdNr. DE 814 013 983


___
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-dev] [congress] ocata client causes feature regression with pre-ocata server

[Eric K]

Hi Tim,
I thought something like that would work. But actually python-congressclient
is not a listed requirement of congress server, no vice versa. Which is
correct in the sense that installing and running one does not require
installing the other on the same machine.

From:  Tim Hinrichs 
Date:  Saturday, January 21, 2017 at 2:33 PM
To:  Eric Kao , "OpenStack Development Mailing
List (not for usage questions)" 
Subject:  Re: [congress] ocata client causes feature regression with
pre-ocata server

> How about we go into the preocata server and change requirements.txt to ensure
> it only supports the older clients. Something like...
> 
> Python-congressclient>2.3<2.5
> 
> Or whatever the versions are.
> 
> Tim
> 
> 
> On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:
>> Hi all,
>> 
>> I was getting ready to request release of congress client, but I
>> remembered that the new client causes feature regression if used with
>> older versions of congress. Specifically, new client with pre-Ocata
>> congress cannot refer to datasource by name, something that could be done
>> with pre-Ocata client.
>> 
>> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
>> 
>> 
>> A few questions:
>> 
>> Are we okay with the regression? Seems like it could cause a fair bit of
>> annoyance for users.
>>1. If we¹re okay with that, what¹s the best way to document that
>> pre-Ocata congress should be used with pre-Ocata client?
>>2. If not, how we avoid the regression? Here are some candidates I can
>> think of.
>>   a. Client detects congress version and act accordingly. I don¹t
>> think this is possible, nor desirable for client to be concerned with
>> congress version not just API version.
>>   b. Release backward compatible API version 1.1 that supports
>> getting datasource by name_or_id. Then client will take different paths
>> depending on API version.
>>   c. If datasource not found, client falls back on old method of
>> retrieving list of datasources to resolve name into UUID. This would work,
>> but causes extra API & DB call in many cases.
>>   d. Patch old versions of Congress to support getting datasource
>> by name_or_id. Essentially, it was always a bug that the API didn¹t
>> support name_or_id.
>> 
>> Thanks!
>> 
>> 


__
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] [congress] ocata client causes feature regression with pre-ocata server

[Tim Hinrichs]

How about we go into the preocata server and change requirements.txt to
ensure it only supports the older clients. Something like...

Python-congressclient>2.3<2.5

Or whatever the versions are.

Tim


On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:

> Hi all,
>
> I was getting ready to request release of congress client, but I
> remembered that the new client causes feature regression if used with
> older versions of congress. Specifically, new client with pre-Ocata
> congress cannot refer to datasource by name, something that could be done
> with pre-Ocata client.
>
> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> 
>
> A few questions:
>
> Are we okay with the regression? Seems like it could cause a fair bit of
> annoyance for users.
>1. If we¹re okay with that, what¹s the best way to document that
> pre-Ocata congress should be used with pre-Ocata client?
>2. If not, how we avoid the regression? Here are some candidates I can
> think of.
>   a. Client detects congress version and act accordingly. I don¹t
> think this is possible, nor desirable for client to be concerned with
> congress version not just API version.
>   b. Release backward compatible API version 1.1 that supports
> getting datasource by name_or_id. Then client will take different paths
> depending on API version.
>   c. If datasource not found, client falls back on old method of
> retrieving list of datasources to resolve name into UUID. This would work,
> but causes extra API & DB call in many cases.
>   d. Patch old versions of Congress to support getting datasource
> by name_or_id. Essentially, it was always a bug that the API didn¹t
> support name_or_id.
>
> Thanks!
>
>
>
__
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] [vote][kolla] deprecation for Debian distro support

[Michał Jastrzębski]

2 as well, on multiple occasions we asked for maintainers to
volunteer, however there have been little response.

On 21 January 2017 at 05:51, Jeffrey Zhang  wrote:
> 2
>
> On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima 
> wrote:
>>
>> 2
>>
>> 2017-01-19 8:50 GMT-03:00 Steven Dake (stdake) :
>>>
>>> My vote is for option 2 to deprecate Debian as there has been very little
>>> activity and operators seem uninterested in Debian as a platform.
>>>
>>> We could always add it back in at a later date if operators were to
>>> request it and the Debian team were interested in maintaining it.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> -Original Message-
>>> From: Christian Berendt 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Thursday, January 19, 2017 at 3:53 AM
>>> To: "openstack-dev@lists.openstack.org"
>>> 
>>> Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro
>>> support
>>>
>>> As discussed in one of the last team meetings I want to propose the
>>> deprecation (this cycle) and removal (next cycle) of the Debian support in
>>> Kolla.
>>>
>>> More than 1 week ago I sent a pre warning mail to the
>>> openstack-operators mailing list, without any reply [0].
>>>
>>> Kolla core reviewers, please vote now. The vote will be open for 7
>>> days (26.01.2017).
>>>
>>> 1. Kolla needs support for Debian, it should not be deprecated
>>>
>>> 2. Kolla should deprecate support for Debian
>>>
>>> [0]
>>> http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html
>>>
>>> --
>>> Christian Berendt
>>> Chief Executive Officer (CEO)
>>>
>>> Mail: bere...@betacloud-solutions.de
>>> Web: https://www.betacloud-solutions.de
>>>
>>> Betacloud Solutions GmbH
>>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>>
>>> Geschäftsführer: Christian Berendt
>>> Unternehmenssitz: Stuttgart
>>> Amtsgericht: Stuttgart, HRB 756139
>>>
>>>
>>>
>>> __
>>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

[Martin Mailand]

Hi Numan,

the security groups were the issue, I deleted them in Openstack, resynced and 
recreated them.

Thanks for your help.

best regards,
 martin

> Am 21.01.2017 um 18:17 schrieb Numan Siddique :
> 
> ​Looks like the Northbound db is not in sync with neutron db.
> Can you run the command "ovn-nbctl list Address_Set" and see if there is a 
> row for the each of the security groups ?
> 
> If you see the ovn northbound db is not in sync, you can sync it by either 
> running the neutron-ovn-db-sync util or by restarting the neutron-server 
> after setting ovn-sync-mode=repair in /etc/neutron/plugins/ml2/ml2_conf.ini


__
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] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

[Numan Siddique]

Adding openstack-dev mailing list as it is more relevant.

Please see inline for some comments.
​​

On Sat, Jan 21, 2017 at 9:12 PM, Martin Mailand  wrote:

> Hi,
>
> I tried to use OVN with Openstack, but I ran into an Issue.
>
> I use the OVN packages from the Canonical Cloud archive:
>
> On the controller node:
> ii  ovn-central  2.6.0-0ubuntu2~cloud0
>amd64OVN central components
> ii  ovn-common   2.6.0-0ubuntu2~cloud0
>amd64OVN common components
> ii  ovn-host 2.6.0-0ubuntu2~cloud0
>amd64OVN host components
> ii  python-networking-ovn1.0.1.dev4.201610261100.xenial-0ubuntu1
> all  OpenStack virtual network service - OVN driver
>
> On the compute node:
>
> ii  ovn-common   2.6.0-0ubuntu2~cloud0
>   amd64OVN common components
> ii  ovn-host 2.6.0-0ubuntu2~cloud0
>   amd64OVN host components
>
> If I create a network in Openstack I can see it in the norhd.
>
> ovn-nbctl show
> switch 5cd02e8c-aa16-4246-932e-c1455958daa6
> (neutron-83a25bd6-494b-4d9d-ba74-e824a8efb826)
>
> And I can see my compute nodes
>
> ovn-sbctl show
> Chassis "4a191104-a3b6-4bde-82ee-1a09ea1b9f17"
> hostname: "compute03"
> Encap vxlan
> ip: "172.16.44.130"
> options: {csum="true"}
> Encap geneve
> ip: "172.16.44.130"
> options: {csum="true"}
> Chassis "b0623e67-a2cf-4802-9343-807383e3eb94"
> hostname: "compute01"
> Encap geneve
> ip: "172.16.44.17"
> options: {csum="true"}
> Encap vxlan
> ip: "172.16.44.17"
> options: {csum="true“}
>
>
> But if I try to start a VM I get an error in the neutron-server log, could
> you please advise me
> where my mistake is?
>
> Best regards,
> martin
>
> log:
>
> 2017-01-21 15:33:42.239 10877 ERROR neutron.agent.ovsdb.impl_idl
> [req-fee0a2c8-b205-4e1e-8756-026880fe84cd 44ea98f941ce412d999b3c3dd7fe1dad
> afc5c0f383314e74bdd6bf1e3afbf509 - - -] Traceback (most recent call last):
>   File 
> "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/native/connection.py",
> line 115, in run
> txn.results.put(txn.do_commit())
>   File "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/impl_idl.py",
> line 105, in do_commit
> ctx.reraise = False
>   File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 220, in __exit__
> self.force_reraise()
>   File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 196, in force_reraise
> six.reraise(self.type_, self.value, self.tb)
>   File "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/impl_idl.py",
> line 100, in do_commit
> command.run_idl(txn)
>   File "/usr/lib/python2.7/dist-packages/networking_ovn/ovsdb/commands.py",
> line 712, in run_idl
> raise RuntimeError(msg)
> RuntimeError: Address set as_ip4_c67f0b5b_ce6f_4a82_aa48_803f00b15300
> does not exist. Can't update addresses
>
>
​Looks like the Northbound db is not in sync with neutron db.
Can you run the command "ovn-nbctl list Address_Set" and see if there is a
row for the each of the security groups ?

If you see the ovn northbound db is not in sync, you can sync it by either
running the neutron-ovn-db-sync util or by restarting the neutron-server
after setting ovn-sync-mode=repair in /etc/neutron/plugins/ml2/ml2_conf.ini

Do you see the same issue with devstack ?

Thanks
Numan


​


> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
> [req-fee0a2c8-b205-4e1e-8756-026880fe84cd 44ea98f941ce412d999b3c3dd7fe1dad
> afc5c0f383314e74bdd6bf1e3afbf509 - - -] Mechanism driver 'ovn' failed in
> create_port_postcommit
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers Traceback
> (most recent call last):
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line
> 433, in _call_on_drivers
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  getattr(driver.obj, method_name)(context)
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py",
> line 556, in create_port_postcommit
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  self.create_port_in_ovn(port, ovn_port_info)
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py",
> line 657, in create_port_in_ovn
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  if_exists=False))
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/api.py", line 76,
> in __exit__
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  self.result = self.commit()
> 

Re: [Openstack-operators] OsOps Reboot

[Melvin Hillsman]

Thanks for the feedback Curtis! I have updated the form to include a short
answer form at the top for typing in custom day/time combinations; Mon-Fri
15:00-22:00 UTC for example.

On Sat, Jan 21, 2017 at 10:24 AM, Curtis  wrote:

> On Thu, Jan 19, 2017 at 11:32 PM, Melvin Hillsman 
> wrote:
> > Good day everyone,
> >
> > As operators we would like to reboot the efforts started around OsOps.
> > Initial things that may make sense to work towards are starting back
> > meetings, standardizing the repos (like having a lib or common folder,
> > READMEs include release(s) tool works with, etc), increasing feedback
> loop
> > from operators in general, actionable work items, identifying
> teams/people
> > with resources for continuous testing/feedback, etc.
> >
> > We have got to a great place so let's increase the momentum and maximize
> all
> > the work that has been done for OsOps so far. Please visit the following
> > link [ https://goo.gl/forms/eSvmMYGUgRK901533 ] to vote on day of the
> week
> > and time (UTC) you would like to have OsOps meeting. And also visit this
> > etherpad [ https://etherpad.openstack.org/p/osops-meeting ] to help
> shape
> > the initial and ongoing agenda items.
>
> The poll is a little unusual. :) I don't know how you are going to get
> a good vote out of it. I would like vote for any time from 15:00 UTC
> to 22:00 UTC from Mon - Fri but not 15:00 UTC on Weds b/c I have
> another meeting at that time. I did put in a vote in your form as
> well, but just kind of put in a single UTC time slot on each day of
> the week.
>
> Thanks,
> Curtis.
>
> >
> > Really appreciate you taking time to read through this email and looking
> > forward to all the great things to come.
> >
> > Also we started an etherpad for brainstorming around how OsOps
> could/would
> > function; very rough draft/outline/ideas right now again please provide
> > feedback: https://etherpad.openstack.org/p/osops-project-future
> >
> >
> > --
> > Kind regards,
> >
> > Melvin Hillsman
> > Ops Technical Lead
> > OpenStack Innovation Center
> >
> > mrhills...@gmail.com
> > phone: (210) 312-1267
> > mobile: (210) 413-1659
> > http://osic.org
> >
> > Learner | Ideation | Belief | Responsibility | Command
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Blog: serverascode.com
>



-- 
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OsOps Reboot

[Curtis]

On Thu, Jan 19, 2017 at 11:32 PM, Melvin Hillsman  wrote:
> Good day everyone,
>
> As operators we would like to reboot the efforts started around OsOps.
> Initial things that may make sense to work towards are starting back
> meetings, standardizing the repos (like having a lib or common folder,
> READMEs include release(s) tool works with, etc), increasing feedback loop
> from operators in general, actionable work items, identifying teams/people
> with resources for continuous testing/feedback, etc.
>
> We have got to a great place so let's increase the momentum and maximize all
> the work that has been done for OsOps so far. Please visit the following
> link [ https://goo.gl/forms/eSvmMYGUgRK901533 ] to vote on day of the week
> and time (UTC) you would like to have OsOps meeting. And also visit this
> etherpad [ https://etherpad.openstack.org/p/osops-meeting ] to help shape
> the initial and ongoing agenda items.

The poll is a little unusual. :) I don't know how you are going to get
a good vote out of it. I would like vote for any time from 15:00 UTC
to 22:00 UTC from Mon - Fri but not 15:00 UTC on Weds b/c I have
another meeting at that time. I did put in a vote in your form as
well, but just kind of put in a single UTC time slot on each day of
the week.

Thanks,
Curtis.

>
> Really appreciate you taking time to read through this email and looking
> forward to all the great things to come.
>
> Also we started an etherpad for brainstorming around how OsOps could/would
> function; very rough draft/outline/ideas right now again please provide
> feedback: https://etherpad.openstack.org/p/osops-project-future
>
>
> --
> Kind regards,
>
> Melvin Hillsman
> Ops Technical Lead
> OpenStack Innovation Center
>
> mrhills...@gmail.com
> phone: (210) 312-1267
> mobile: (210) 413-1659
> http://osic.org
>
> Learner | Ideation | Belief | Responsibility | Command
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Blog: serverascode.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] How to troubleshoot Security Group rules

[Vimal Kumar]

I am facing a mysterious situation. I am using LinuxBridge (ML2) on
OpenStack Newton all-in-one. I set up tcpdump on the tap device used by the
instance and then attach a floating ip from web UI. I see traffic flowing
for a few seconds after which there is no further traffic in/out of this
tap device. During the first few seconds, I am able to ssh into the
instance using the pubic ip. After 5-7 seconds, no connection could be
established from the Internet. However I am still able to ssh into the
instance if I execute ssh w.r.t the corresponding network namespace, like:

# ip netns exec  ssh cirros@

Why is this happening? I do not see any specific errors in neutron logs
even with debug on.

Attaching the relevant configs below.



# grep -Ev '^#|^$' /etc/nova/nova.conf
[DEFAULT]
auth_strategy = keystone
disk_allocation_ratio=10.0
my_ip = 
use_neutron = True
enabled_apis = osapi_compute,metadata
firewall_driver = nova.virt.firewall.NoopFirewallDriver
transport_url = rabbit://
openstack:55de10077d1f953e8...@openstack.mycloud.com
[api_database]
connection = mysql+pymysql://
nova:9a55c0c04085248aa...@openstack.mycloud.com/nova_api
[barbican]
[cache]
[cells]
[cinder]
os_region_name = RegionOne
[cloudpipe]
[conductor]
[cors]
[cors.subdomain]
[crypto]
[database]
connection = mysql+pymysql://
nova:9a55c0c04085248aa...@openstack.mycloud.com/nova
[ephemeral_storage_encryption]
[glance]
api_servers = http://openstack.mycloud.com:9292
[guestfs]
[hyperv]
[image_file_url]
[ironic]
[key_manager]
[keystone_authtoken]
auth_uri = http://openstack.mycloud.com:5000
auth_url = http://openstack.mycloud.com:35357
memcached_servers = openstack.mycloud.com:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = nova
password = 57227b66ed883b739e0b
[libvirt]
virt_type=kvm
[matchmaker_redis]
[metrics]
[mks]
[neutron]
url = http://openstack.mycloud.com:9696
auth_url = http://openstack.mycloud.com:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = neutron
password = 8b229c60d8faf31da416
service_metadata_proxy = True
metadata_proxy_shared_secret = d37bee945996e7ed5100
[osapi_v21]
[oslo_concurrency]
lock_path=/var/lib/nova/tmp
[oslo_messaging_amqp]
[oslo_messaging_notifications]
[oslo_messaging_rabbit]
[oslo_messaging_zmq]
[oslo_middleware]
[oslo_policy]
[placement]
[placement_database]
[rdp]
[remote_debug]
[serial_console]
[spice]
[ssl]
[trusted_computing]
[upgrade_levels]
[vmware]
[vnc]
enabled=true
vncserver_listen = $my_ip
vncserver_proxyclient_address = $my_ip
novncproxy_base_url = http://openstack.mycloud.com:6080/vnc_auto.html
[workarounds]
[wsgi]
[xenserver]
[xvp]




# grep -Ev '^#|^$' /etc/neutron/l3_agent.ini
[DEFAULT]
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
debug = true
[AGENT]




# grep -Ev '^#|^$' /etc/neutron/dhcp_agent.ini
[DEFAULT]
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True
[AGENT]




# grep -Ev '^#|^$' /etc/neutron/metadata_agent.ini
[DEFAULT]
nova_metadata_ip = openstack.mycloud.com
metadata_proxy_shared_secret = d37bee945996e7ed5100
[AGENT]
[cache]




# grep -Ev '^#|^$' /etc/neutron/neutron.conf
[DEFAULT]
auth_strategy = keystone
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
notify_nova_on_port_status_changes = true
notify_nova_on_port_data_changes = true
debug = true
transport_url = rabbit://
openstack:55de10077d1f953e8...@openstack.mycloud.com
[agent]
[cors]
[cors.subdomain]
[database]
connection = mysql+pymysql://
neutron:60f65e693265e4499...@openstack.mycloud.com/neutron
[keystone_authtoken]
auth_uri = http://openstack.mycloud.com:5000
auth_url = http://openstack.mycloud.com:35357
memcached_servers = openstack.mycloud.com:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = neutron
password = 8b229c60d8faf31da416
[matchmaker_redis]
[nova]
auth_url = http://openstack.mycloud.com:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = nova
password = 57227b66ed883b739e0b
[oslo_concurrency]
lock_path = /var/lib/neutron/tmp
[oslo_messaging_amqp]
[oslo_messaging_notifications]
[oslo_messaging_rabbit]
[oslo_messaging_zmq]
[oslo_middleware]
[oslo_policy]
[qos]
[quotas]
[ssl]





# grep -Ev '^#|^$' /etc/neutron/plugin.ini
[DEFAULT]
debug = true
[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = linuxbridge,l2population
extension_drivers = port_security
[ml2_type_flat]
flat_networks = provider
[ml2_type_geneve]
[ml2_type_gre]
[ml2_type_vlan]
[ml2_type_vxlan]
vni_ranges = 1:1000
[securitygroup]
enable_ipset = True




On Fri, Jan 20, 2017 at 2:49 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> Checkout on the 

Re: [openstack-dev] [tripleo] Atlanta PTG

[Emilien Macchi]

On Sat, Jan 21, 2017 at 5:37 AM, Michele Baldessari  wrote:
> Hi Emilien,
>
> while not a design session per se, I would love to propose a short slot
> for TripleO CI Q, if we have some time left. In short, I'd like to be
> more useful around CI failures, but I lack the understanding of a few
> aspects of our current CI (promotion, when do images get built, etc.),
> that would benefit quite a bit from a short session where we have a few
> CI folks in the room that could answer questions or give some tips.
> I know of quite few other people that are in the same boat and maybe
> this will help a bit our current issue where only a few folks always
> chase CI issues.
>
> If there is consensus (and some CI folks willing to attend ;) and time
> for this, I'll be happy to organize this and prepare a bunch of
> questions ideas beforehand.

That would be *awesome* and yes we'll take time to do it, and even
record it if possible.

Thank you!

> Thoughts?
> Michele
>
> On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
>> I would like to bring this topic up on your inbox, so we can continue
>> to make progress on the agenda. Feel free to follow existing examples
>> in the etherpad and propose a design dession.
>>
>> Thanks,
>>
>> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi  wrote:
>> > General infos about PTG: https://www.openstack.org/ptg/
>> >
>> > Some useful informations about PTG/TripleO:
>> >
>> > * When? We have a room between Wednesday and Friday included.
>> > Important sessions will happen on Wednesday and Thursday. We'll
>> > probably have sessions on Friday, but it might be more hands-on and
>> > hackfest, where people can enjoy the day to work together.
>> >
>> > * Let's start to brainstorm our topics:
>> > https://etherpad.openstack.org/p/tripleo-ptg-pike
>> >   Feel free to add any topic, as soon as you can. We need to know asap
>> > which sessions will be share with other projects (eg: tripleo/mistral,
>> > tripleo/ironic, tripleo/heat, etc).
>> >
>> >
>> > Please let us know any question or feedback,
>> > Looking forward to seeing you there!
>> > --
>> > Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __
>> 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
>
> --
> Michele Baldessari
> C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D



-- 
Emilien Macchi

__
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] Improving Vendor Driver Discoverability

[Hayes, Graham]

On 20/01/17 01:40, Mike Perez wrote:
> On 17:38 Jan 18, Morales, Victor wrote:
>> Just a FYI, Ankur have been working on have a Feature Classification Matrix
>> in Neutron[1] which collects some of this information
>>
>> [1] https://review.openstack.org/#/c/318192/
> 
> I actually didn't know Nova also generated this with a script and ini file.
> Perhaps this would be a better approach than a giant JSON file like driver log
> is today. I could then have the marketplace parse these ini files using the
> common script. What do others think?
> 

FWIW Designate also does this - [0] is generated by [1] and a modified
version of the Nova script.

If there is a common way, we will use that, but I like our current
implementation.

0 - http://docs.openstack.org/developer/designate/support-matrix.html
1 -
https://git.openstack.org/cgit/openstack/designate/tree/doc/source/support-matrix.ini


__
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] [vote][kolla] deprecation for Debian distro support

[Jeffrey Zhang]

2

On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima 
wrote:

> 2
>
> 2017-01-19 8:50 GMT-03:00 Steven Dake (stdake) :
>
>> My vote is for option 2 to deprecate Debian as there has been very little
>> activity and operators seem uninterested in Debian as a platform.
>>
>> We could always add it back in at a later date if operators were to
>> request it and the Debian team were interested in maintaining it.
>>
>> Regards
>> -steve
>>
>>
>> -Original Message-
>> From: Christian Berendt 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: Thursday, January 19, 2017 at 3:53 AM
>> To: "openstack-dev@lists.openstack.org" > .org>
>> Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro
>> support
>>
>> As discussed in one of the last team meetings I want to propose the
>> deprecation (this cycle) and removal (next cycle) of the Debian support in
>> Kolla.
>>
>> More than 1 week ago I sent a pre warning mail to the
>> openstack-operators mailing list, without any reply [0].
>>
>> Kolla core reviewers, please vote now. The vote will be open for 7
>> days (26.01.2017).
>>
>> 1. Kolla needs support for Debian, it should not be deprecated
>>
>> 2. Kolla should deprecate support for Debian
>>
>> [0] http://lists.openstack.org/pipermail/openstack-operators/201
>> 7-January/012427.html
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: bere...@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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:unsubscrib
>> e
>> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Davanum Srinivas]

"keystoneauth1 >= 2.17.0" implies python-novaclient with your fix will
work for any version including 2.17.0 which is not true. you need to
either do "keystoneauth1 >= 2.18.0" or "keystoneauth1 > 2.17.0" and we
prefer the ">=" notation i think.

Thanks,
Dims

On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek
 wrote:
> Hi Dims,
>
> Thank you for reply. I will propose a patch soon. Just for curiosity,
> keystoneauth1 >= 2.17.0 will not install 2.18.0?
>
> Abhishek
> 
> From: Davanum Srinivas 
> Sent: Saturday, January 21, 2017 8:27:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][
> python-cinderclient][ python-neutronclient] Remove x-openstack-request-id
> logging code as it is logged twice
>
> Abhishek,
>
> 1) requirements.txt for all 4 python-*client you mentioned have
> "keystoneauth1>=2.17.0",
> 2) i do not see a review request to bump the minimum version in global
> requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
> (https://review.openstack.org/#/q/project:openstack/requirements+is:open)
>
> Can you please file one?
>
> Thanks,
> Dims
>
>
> On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek
>  wrote:
>> Hi Devs,
>>
>>
>>
>> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is
>> logged
>> for every HTTP response. This keystoneauth1 version will be used for
>> ocata.
>>
>> The same request id is also logged in 'request' method of SessionClient
>> class for python-novaclient, python-glanceclient, python-cinderclient and
>> python-neutronclient. Once requirements.txt is synced with
>> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
>> x-openstack-request-id will be logged twice for these clients.
>>
>>
>>
>> I have submitted patches for python-novaclient [1] and python-glanceclient
>> [2] and created patches for python-cinderclient and python-neutronclient
>> but
>> same will not be reviewed unless and until the requirements.txt is synced
>> with global-requirements and it uses keystoneauth1 version 2.18.0.
>>
>>
>>
>> As final releases for client libraries are scheduled in the next week
>> (between Jan 23 - Jan 27) we want to address these issues in the above
>> mentioned clients.
>>
>>
>>
>> Please let us know your opinion about the same.
>>
>>
>>
>> [1] https://review.openstack.org/422602
>>
>> [2] https://review.openstack.org/422591
>>
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>> __
>> 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
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Steve,

Thank you for the update. I have already submitted patches for 
python-novaclient and python-novaclient for reviews and ready with 
python-cinderclient and python-novaclient patches. I will submit them ASAP when 
requirements.txt is synced with updated version of keystoneauth1.

Thank you,

Abhishek

From: Steve Martinelli 
Sent: Saturday, January 21, 2017 10:07:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice



On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek 
> wrote:
Hi Dims,

Thank you for reply. I will propose a patch soon. Just for curiosity, 
keystoneauth1 >= 2.17.0 will not install 2.18.0?

It will, but if we make 2.18.0 the minimum then it will for sure install only 
that level.

> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.

So I approved this change (sorry it took so long to review and merge), but I 
didn't realize it was going to impact python-{nova | glance | cinder | 
neutron}client. I think it's slightly unrealistic to ask four teams to remove 
the logging in the last week we release clients (I'm assuming we want to remove 
the functionality and not log things twice).

 - Would folks prefer I revert the keystoneauth change and re-release without 
it, and we can bring it back in Pike?
- Do teams have the bandwidth to remove the request id logging in the next few 
days?

Sorry for the confusion this caused.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [telemetry][ptl] Candidacy for Pike

[Julien Danjou]

Hi!

As I can observe every end of cycle, the Telemetry team has been doing an
amazing job making progress on the projects we manage this cycle. Gnocchi
gained features and traction, Aodh got new contributors, Panko started his own
destiny and Ceilometer is reducing and improving its footprint.

If you look at the release goals that have been decided or are being discussed
(Python 3.5, mod_wsgi deployment, oslo usage…), you will notice our projects
are way ahead and I think it's tremendous. And our team is continuously
improving the rest of OpenStack by contributing to Oslo too. I reiterate what I
said last cycle: think it's a great achievement for a small team like us.

So, yes, I envision us continuing on this trajectory, setting the bar higher
for everyone. That's why I'm running again this time to serve the team,
managing the project in a transparent way and do everything I can to grow our
community and make people feel welcome.

We all know how barely useful we made the PTL be, and I count on keeping it
that way. :-)

Happy hacking,

(For reference, review: https://review.openstack.org/#/c/423125/)

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


signature.asc
Description: PGP signature
__
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] [tripleo] Atlanta PTG

[Michele Baldessari]

Hi Emilien,

while not a design session per se, I would love to propose a short slot
for TripleO CI Q, if we have some time left. In short, I'd like to be
more useful around CI failures, but I lack the understanding of a few
aspects of our current CI (promotion, when do images get built, etc.),
that would benefit quite a bit from a short session where we have a few
CI folks in the room that could answer questions or give some tips.
I know of quite few other people that are in the same boat and maybe
this will help a bit our current issue where only a few folks always
chase CI issues.

If there is consensus (and some CI folks willing to attend ;) and time
for this, I'll be happy to organize this and prepare a bunch of
questions ideas beforehand.

Thoughts?
Michele

On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
> I would like to bring this topic up on your inbox, so we can continue
> to make progress on the agenda. Feel free to follow existing examples
> in the etherpad and propose a design dession.
> 
> Thanks,
> 
> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi  wrote:
> > General infos about PTG: https://www.openstack.org/ptg/
> >
> > Some useful informations about PTG/TripleO:
> >
> > * When? We have a room between Wednesday and Friday included.
> > Important sessions will happen on Wednesday and Thursday. We'll
> > probably have sessions on Friday, but it might be more hands-on and
> > hackfest, where people can enjoy the day to work together.
> >
> > * Let's start to brainstorm our topics:
> > https://etherpad.openstack.org/p/tripleo-ptg-pike
> >   Feel free to add any topic, as soon as you can. We need to know asap
> > which sessions will be share with other projects (eg: tripleo/mistral,
> > tripleo/ironic, tripleo/heat, etc).
> >
> >
> > Please let us know any question or feedback,
> > Looking forward to seeing you there!
> > --
> > Emilien Macchi
> 
> 
> 
> -- 
> Emilien Macchi
> 
> __
> 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

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] [ironic-pyhon-agent][DIB] IPA failed to start on Ubuntu because of modprobe path

[Moshe Levi]

Hi,
This commit 
https://github.com/openstack/diskimage-builder/commit/2854f4063bd2a6dcdb6fa5fab93aa56857e47b59
 
Added ExecStartPre=/usr/sbin/modprobe vfat to the ironic-python-agent systemd 
script 
The problem is that modprobe location in Ubuntu / sbin/modprobe (the 
/usr/sbin/modprobe vfat works for redhat)
I have opened this bug in Launchpad 
https://bugs.launchpad.net/diskimage-builder/+bug/1658297  
This break IPA element when building with Ubunut OS.
Is there conditional in systemd scripts like 
If os == Redhat then
ExecStartPre=/usr/sbin/modprobe vfat
Elseif os == Ubuntu  then
ExecStartPre=/sbin/modprobe vfat

What is the best way to fix this? 

Thanks,
Moshe Levi



__
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] [cinder] Can I use lvm thin provisioning in mitaka?

[Marco Marino]

Really thank you!! It's difficult for me find help on cinder and I think
this is the right place!
@Duncan, if my goal is to speeding up bootable volume creation, I can avoid
to use thin provisioning. I can use image cache and in this way the
"retrieve from glance" and the "qemu-img convert to RAW" parts will be
skipped. Is this correct? And whit this method I don't have a performancy
penalty mentioned by Chris.
@Chris: Yes, I'm using volume_clear option and volume deletion is very fast

Marco



2017-01-20 18:24 GMT+01:00 Duncan Thomas :

> There's also cinder functionality called the 'generic image cache' that
> does this for you; see the (per-backend) config options:
> image_volume_cache_enabled, image_volume_cache_max_size_gb and
> image_volume_cache_max_count
>
> On 20 January 2017 at 16:54, Chris Friesen 
> wrote:
>
>> On 01/20/2017 04:07 AM, Marco Marino wrote:
>>
>>> Hi, I'm trying to use cinder with lvm thin provisioning. It works well
>>> and I'd
>>> like to know if there is some reason lvm thin should be avoided in mitaka
>>> release. I'm trying to use with
>>> max_over_subscription_ratio = 1.0
>>> so I don't have problems with over subscription.
>>> I using thin provisioning because it is fast (I think). More precisely,
>>> my use
>>> case is:
>>>
>>> - create one bootable volume. This is a long operation because cinder
>>> download
>>> the image from glance, qemu-img convert in raw format and then "dd" copy
>>> the
>>> image in the volume.
>>> - Create a snapshot of the bootable volume. Really fast and reliable
>>> because the
>>> original volume is not used by any vm.
>>> - Create a new volume from the snapshot. This is faster than create a new
>>> bootable volume.
>>>
>>> Is this use correct? Can I deploy in the production environment (mitaka
>>> - centos 7)
>>> Thank you
>>>
>>
>> For what it's worth we're using cinder with LVM thin provisioning in
>> production with no overprovisioning.
>>
>> What you're proposing should work, you're basically caching the vanilla
>> image as a cinder snapshot.
>>
>> If you wish to speed up volume deletion, you can set "volume_clear=none"
>> in the cinder.conf file.
>>
>> Be aware that LVM thin provisioning will see a performance penalty the
>> first time you write to a given disk block in a volume, because it needs to
>> allocate a new block, zero it out, then write the new data to it.
>>
>> Chris
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> --
> Duncan Thomas
>
> __
> 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