[openstack-dev] [QA] Meeting Thursday Aug 24th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Aug 24th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
 
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_August_24th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.
-gmann

__
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] transfer of IP address between ports

[Volodymyr Litovka]

Hi Clint,

see inline, please.

On 8/24/17 2:21 AM, Clint Byrum wrote:

This is precisely the reason floating IPs that NAT to other IPs exists
(not, as we think, to provide public IP access... we can do that with
fixed IPs).

Moving ports, moving the IP, they all involve a few layers of cache
invalidation and complex manipulation at the lower networking layers. But
changing a NAT destination is relatively instant.

I'd recommend you using a floating IP for this. If you can't, please
explain.
It's going to be public cloud and there can be few reasons to allow 
customer to move pubic IP address between his VMs, e.g. he built another 
VM using another OS for same role and need to move this role from old VM 
to new VM, do not changing other infrastructure's configurations.


Thanks.


Excerpts from Volodymyr Litovka's message of 2017-08-23 16:58:32 +0300:

Hi colleagues,

imagine, somebody (e.g. me :-) ) needs to transfer IP address between
two ports. The straight way is: release IP address and then assign it to
another port.

The possible problem with this way is time between release and
assignment - during this time, this IP address is in DHCP pool and can
be automatically assigned to some another port upon request.

Any ideas how to prevent leasing this IP address during this time?

Thank you.


___
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


--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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-dev] [nova] Less than 24 hours to Pike RC2

[Matt Riedemann]

This is just a reminder that we're in the final stretch for Pike RC2 
which happens tomorrow.


There are a couple of fixes in flight yet for RC2 at the top of the 
etherpad:


https://etherpad.openstack.org/p/nova-pike-release-candidate-todo

And another bug that Alex pointed out tonight not yet reported in 
launchpad, but we don't cleanup allocations from the current node before 
doing a reschedule. If you have Ocata computes or are doing 
super-conductor mode tiered conductors for cells v2 then it's not an 
issue, but any installs that are doing single conductor relying on 
reschedules will have this issue, which I'd consider something we should 
fix for RC2 as it means we'll be reporting usage against compute nodes 
in Placement which isn't really there, thus potentially taking them out 
of scheduling decisions.


If you find anything else in the next few hours, please report a bug and 
tag it with pike-rc-potential.


--

Thanks,

Matt

__
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] [all][QA][group-based-policy][zaqar][packaging_deb][fuel][networking-*] Marking <= mitaka EOL

[Tony Breeds]

Hello all,
We have a number of old stable/* branches hanging around and I'd
like to mark anything <= stable/mitaka as EOL.  I've highlighted a few
projects on the subject line:

QA: Are the older branches of grenade safe to go?  IIUC we don't use
them as we don't do grenade testing on $oldest stable branch
group-based-policy: In the past you've requested your old branches stay
around Do you still need this?  Is there value in
the *all* staying active?
zaqar: I see that liberty was EOL and then reactivated do you still need
   liberty2?
packaging_deb: As these repos have the $project origin using the
   standard series-eol tag doesn't make sense  for exaxple
   deb-nova gets a mitaka-eol from the nova repo.   So I've
   picked mitaka-eol-dpkg.
fuel, networking-*: There are several entries for these projects groups
so I'm calling them out here for attention.

I'm proposing we do this removal during the PTG.  Once we've done the
series based branches we can look at old versioned releases like
stable/16.04 etc.

It's hard to present the data in a clear way so given infra will be the
ultimate actioners of this list I present this as a shell script:

---
eol-branch.sh -- stable/essex essex-eol openstack/anvil
eol-branch.sh -- stable/folsom folsom-eol openstack/anvil
eol-branch.sh -- stable/grizzly grizzly-eol openstack/anvil
eol-branch.sh -- stable/havana havana-eol openstack/openstack
eol-branch.sh -- stable/icehouse icehouse-eol \
 openstack/astara openstack/networking-brocade \
 openstack/networking-cisco openstack/networking-mlnx \
 openstack/networking-odl openstack/networking-plumgrid \
 openstack/nova-solver-scheduler \
 openstack/sahara-image-elements openstack/tricircle \
 openstack/trio2o openstack/vmware-nsx
eol-branch.sh -- stable/icehouse icehouse-eol-dpkg \
 openstack/deb-networking-cisco \
 openstack/deb-networking-mlnx openstack/deb-networking-odl
eol-branch.sh -- stable/juno juno-eol \
 openstack/astara openstack/astara-appliance \
 openstack/astara-horizon openstack/astara-neutron \
 openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui openstack/mistral \
 openstack/mistral-dashboard openstack/mistral-extra \
 openstack/networking-bigswitch \
 openstack/networking-brocade openstack/networking-cisco \
 openstack/networking-mlnx openstack/networking-odl \
 openstack/networking-plumgrid \
 openstack/nova-solver-scheduler \
 openstack/openstack-resource-agents \
 openstack/powervc-driver openstack/proliantutils \
 openstack/puppet-n1k-vsm openstack/puppet-vswitch \
 openstack/python-group-based-policy-client \
 openstack/python-mistralclient \
 openstack/python-muranoclient openstack/vmware-nsx
eol-branch.sh -- stable/juno juno-eol-dpkg \
 openstack/deb-mistral openstack/deb-networking-cisco \
 openstack/deb-networking-mlnx openstack/deb-networking-odl \
 openstack/deb-python-mistralclient \
 openstack/deb-python-muranoclient \
 openstack/deb-python-proliantutils
eol-branch.sh -- stable/kilo kilo-eol \
 openstack-dev/grenade openstack/murano-apps \
 openstack/networking-h3c openstack/requirements
eol-branch.sh -- stable/kilo kilo-eol1 \
 openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui \
 openstack/python-group-based-policy-client
eol-branch.sh -- stable/kilo_v2 kilo_v2-eol openstack/networking-bigswitch
eol-branch.sh -- stable/liberty liberty-eol \
 openstack-dev/grenade openstack/ceilometer-powervm \
 openstack/ceilometer-zvm openstack/ceilometermiddleware \
 openstack/fuel-plugin-calico openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui openstack/mistral-extra \
 openstack/networking-infoblox openstack/networking-powervm \
 openstack/networking-zvm openstack/nova-powervm \
 openstack/nova-zvm-virt-driver \
 openstack/python-group-based-policy-client \
 openstack/requirements openstack/swiftonhpss
eol-branch.sh -- stable/liberty liberty-eol-dpkg \
 openstack/deb-aodh openstack/deb-barbican \
 openstack/deb-ceilometer \
 openstack/deb-ceilometermiddleware 

Re: [openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !

[ChangBo Guo]

Ken,  I just search debtcollector usage to find deprecated stuff,  we still
have other things to clean up,  feel free to add items in the etherpad.

2017-08-23 21:32 GMT+08:00 Ken Giusti :

>
>
> On Tue, Aug 22, 2017 at 3:24 AM, ChangBo Guo  wrote:
>
>> Hi ALL,
>>
>> We discussed a little about how to avoid breaking consuming projects'
>> gate in oslo weekly meeting last week.  The easy improvement is that clean
>> up deprecated stuff in oslo at the beginning of Queens.  I collected
>> deprecated stuff  in [1].  This need Oslo team and other team work
>> toghether. I think we can start the work when cycle Queens is open. I
>> also reserved a room in PTG
>> for 2 hours to do hacking.[2]
>>
>>
>> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
>> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>>
>> --
>> ChangBo Guo(gcb)
>>
>> 
>> __
>> 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
>>
>>
> I've gone through oslo.messaging and have updated the etherpad [1] with a
> few more entries.  I've opened launchpad bugs where appropriate, adding the
> oslo-debt-cleanup tag to each for good measure.
>
> The original list included a few items that as best I can tell were not
> tagged as deprecated via debtcollector until Pike. IIUC we can't remove
> those in Queens, correct?
>
> --
> Ken Giusti  (kgiu...@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
>
>


-- 
ChangBo Guo(gcb)
__
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] [charms][ptg] PTG planning pad

[Billy Olsen]

A reminder that the PTG is only 2 1/2 weeks away. Please remember to
take time to add any topics that you wish to discuss or sprint on
during the week.

https://etherpad.openstack.org/p/ptg-queens-charms

Thanks,

Billy

On Wed, Aug 9, 2017 at 2:14 AM, James Page  wrote:
> Hi All
>
> I've started a planning etherpad for the PTG next month; feel free to add
> topics you want to discuss/sprint on during the week.
>
>   https://etherpad.openstack.org/p/ptg-queens-charms
>
> Cheers
>
> James
>
> __
> 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] transfer of IP address between ports

[Clint Byrum]

This is precisely the reason floating IPs that NAT to other IPs exists
(not, as we think, to provide public IP access... we can do that with
fixed IPs).

Moving ports, moving the IP, they all involve a few layers of cache
invalidation and complex manipulation at the lower networking layers. But
changing a NAT destination is relatively instant.

I'd recommend you using a floating IP for this. If you can't, please
explain.

Excerpts from Volodymyr Litovka's message of 2017-08-23 16:58:32 +0300:
> Hi colleagues,
> 
> imagine, somebody (e.g. me :-) ) needs to transfer IP address between 
> two ports. The straight way is: release IP address and then assign it to 
> another port.
> 
> The possible problem with this way is time between release and 
> assignment - during this time, this IP address is in DHCP pool and can 
> be automatically assigned to some another port upon request.
> 
> Any ideas how to prevent leasing this IP address during this time?
> 
> Thank you.
> 

___
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-Infra] Infra Team PTG Dinner

[Paul Belanger]

On Wed, Aug 23, 2017 at 02:21:07PM -0700, Clark Boylan wrote:
> Hello,
> 
> I brought this up briefly in yesterday's meeting, but are we interested
> in having a team dinner while at the PTG? I expect we are so I've tried
> to start putting information together at
> https://etherpad.openstack.org/p/infra-ptg-team-dinner.
> 
> The biggest issue is there does not appear to be a lot of options near
> the PTG hotel. That said, there appears to be a good beer garden option
> about 4 miles away. Beer gardens were a hit in Darmstadt because they
> can accomodate large groups, we don't have to pre negotiate reservations
> or who is paying, and of course because beer.
> 
> If interested please add your name to the list on the etherpad and the
> evenings you are available for the dinner. Also, if anyone else has
> better ideas (seriously I'm not great at this) or wants to organize go
> ahead and edit the etherpad and/or let me know.
> 
As somebody who did Boston, I'm okay with whatever you choose. :)

> Thanks,
> Clark
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

[OpenStack-Infra] Infra Team PTG Dinner

[Clark Boylan]

Hello,

I brought this up briefly in yesterday's meeting, but are we interested
in having a team dinner while at the PTG? I expect we are so I've tried
to start putting information together at
https://etherpad.openstack.org/p/infra-ptg-team-dinner.

The biggest issue is there does not appear to be a lot of options near
the PTG hotel. That said, there appears to be a good beer garden option
about 4 miles away. Beer gardens were a hit in Darmstadt because they
can accomodate large groups, we don't have to pre negotiate reservations
or who is paying, and of course because beer.

If interested please add your name to the list on the etherpad and the
evenings you are available for the dinner. Also, if anyone else has
better ideas (seriously I'm not great at this) or wants to organize go
ahead and edit the etherpad and/or let me know.

Thanks,
Clark

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

Re: [openstack-dev] [all] review.openstack.org downtime and Gerrit upgrade

[Clark Boylan]

On Wed, Aug 2, 2017, at 03:57 PM, Clark Boylan wrote:
> Hello,
> 
> The Infra team is planning to upgrade review.openstack.org from Gerrit
> 2.11 to Gerrit 2.13 on September 18, 2017. This downtime will begin at
> 1500UTC and is expected to take many hours as we have to perform an
> offline update of Gerrit's secondary indexes. The outage should be
> complete by 2359UTC.
> 
> This upgrade is a relatively minor one for users. You'll find that
> mobile use of Gerrit is slightly better (though still not great). The
> bug that forces us to reapply Approval votes rather than just rechecking
> has also been addressed. If you'd like to test out Gerrit 2.13 you can
> do so at https://review-dev.openstack.org.
> 
> The date we have chosen is the Monday after the PTG. The
> expectation/hope is that many people will still be traveling or
> otherwise recovering from the PTG so demand for Gerrit will be low. By
> doing it on Monday we also hope that there will be load on the service
> the following day which should help shake out any issues quickly (in the
> past we've done it on weekends then had to wait a couple days before
> problems are noticed).
> 
> If you have any concerns or feedback please let the Infra team know.
> 
> Thank you,
> Clark

This is a friendly reminder that we will be upgrading Gerrit on
review.openstack.org the Monday after PTG. Expect a prolonged service
outage. Once again let us know if you have any questions or concerns.

Thank you,
Clark

__
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] [ironic]clean failed after I finished clean-step

[Richard.Pioso]

Greetings,

Thank you for your question.  Hopefully, I can help you move beyond the node 
cleaning issue you encountered.

To begin, I have a couple of observations.


1.   It seems that automated cleaning was attempted.  Please note that the 
DRAC driver does not implement any automated cleaning steps.  The RAID cleaning 
steps it offers can be used by manual cleaning.

2.   The iDRAC driver code that detected an issue with the clean step(s) 
configured on the node has been removed on master and in the forthcoming 9.1.0 
(Pike) release of ironic.  That was done to fix the bug “double manage/provide 
cycle cause trace for pxe_drac” 
(https://bugs.launchpad.net/ironic/+bug/1676387).  That bug is not related to 
your issue.

Beyond that, to further assist you, I need the following information.


1.   Which distribution of ironic are you using?

2.   What is ironic’s version?

3.   Please describe how the clean steps were set to configure RAID.  I am 
looking for the API requests or CLI commands that were issued.

4.  What was the state of the ironic node before it was provided?  That can be 
retrieved by either of the following CLI commands, depending on the version of 
the ironic client you are using.

ironic node-show 
openstack baremetal node show 

Thank you, and regards,
Rick

From: 王俊 [mailto:wang...@yovole.com]
Sent: Wednesday, August 23, 2017 3:52 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ironic]clean failed after I finished clean-step

Hi:
anybody saw this before?http://paste.openstack.org/show/619133/
I typed clean-step to config raid,after that,the node status was in 
manageable,then I made status to provide,the error appeared.
I don’t know how to fixed it

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
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] [cinder] cinder 11.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/pike

Release notes for cinder can be found at:

http://docs.openstack.org/releasenotes/cinder/




__
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] [nova] [placement] [api] cache headers in placement service

[Chris Dent]

On Mon, 21 Aug 2017, Chris Dent wrote:


Essentially so we can put last-modified headers on things, which in
RFC speak we SHOULD do. And if we do that then we SHOULD make sure
no caching happens.


For sake of completeness, I've gone ahead and proposed a spec for
this:

https://review.openstack.org/#/c/496853/

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [glance] docs: architecture or hw_architecture

[Clint Byrum]

Excerpts from Dean Troyer's message of 2017-08-23 13:48:07 -0500:
> On Wed, Aug 23, 2017 at 12:33 PM, Brian Rosmaita
>  wrote:
> > My point is just that Glance went one way on this, Nova went a
> > different way, and users are left hanging.  My secondary point is that
> > it might be useful to catalog these things in the metadata definitions
> > service so that we all stay on the same page better.
> 
> This is a great example of why attributes that are actually used
> elsewhere should be defined in the API rather than just picked out of
> a collection of metadata/properties.

Note that there was at least an effort at one time to create a
definitive place to share tags across OpenStack projects and across
clouds:

https://wiki.openstack.org/wiki/Graffiti

I don't know where this is at these days, but I would agree that I'd
rather see any guarantees a service provides documented and expressed in
its API. When one project's objects are referenced in anothers' API,
that's a good place for those two projects to work very closely
together. It looks like that didn't quite happen here. A quick doc fix
should resolve the matter, or is the use of 'architecture' now in other
places?

__
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-operators] cinder/nova issues

[Adam Dibiase]

Thanks Sean. I filed a bug report to track this. Bug #1712651. I would
agree with you on connectivity issues with the Netapp if it happened on all
volume extensions, but this only happens in one scenario only.

Thanks,

Adam




On Wed, Aug 23, 2017 at 2:04 PM, Sean McGinnis 
wrote:

> Hey Adam,
>
> There have been some updates since Liberty to improve handling in the
> os-brick
> library that handles the local device management. But with this showing the
> paths down, I wonder if there's something else going on there between the
> NetApp box and the Nova compute host.
>
> Could you file a bug to track this? I think you could just copy and paste
> the
> content of your original email since it captures a lot of great info.
>
> https://bugs.launchpad.net/cinder/+filebug
>
> We can tag it with netapp so maybe it will get some attention there.
>
> Thanks,
> Sean
>
> On Wed, Aug 23, 2017 at 01:01:24PM -0400, Adam Dibiase wrote:
> > Greetings,
> >
> > I am having an issue with nova starting an instance that is using a root
> > volume that cinder has extended. More specifically, a volume that has
> been
> > extended past the max resize limit of our Netapp filer. I am running
> > Liberty and upgraded cinder packages to 7.0.3 from 7.0.0 to take
> advantage
> > of this functionality. From what I can gather, it uses sub-lun cloning to
> > get past the hard limit set by Netapp when cloning past 64G (starting
> from
> > a 4G volume).
> >
> > *Environment*:
> >
> >- Release: Liberty
> >- Filer:   Netapp
> >- Protocol: Fiberchannel
> >- Multipath: yes
> >
> >
> >
> > *Steps to reproduce: *
> >
> >- Create new instance
> >- stop instance
> >- extend the volume by running the following commands:
> >   - cinder reset-state --state available (volume-ID or name)
> >   - cinder extend (volume-ID or name) 100
> >   - cinder reset-state --state in-use (volume-ID or name)
> >- start instance with either nova start or nova reboot --hard  --same
> >result
> >
> >
> > I can see that the instance's multipath status is good before the
> resize...
> >
> > *360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *
> >
> > size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
> >
> > |-+- policy='round-robin 0' prio=-1 status=active
> >
> > | |- 6:0:1:5 sdy   65:128 active undef  running
> >
> > | `- 7:0:0:5 sdz   65:144 active undef  running
> >
> > `-+- policy='round-robin 0' prio=-1 status=enabled
> >
> >   |- 6:0:0:5 sdx   65:112 active undef  running
> >
> >   `- 7:0:1:5 sdaa  65:160 active undef  running
> >
> >
> > Once the volume is resized, the lun goes to a failed state and it does
> not
> > show the new size:
> >
> >
> > *360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *
> >
> > size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
> >
> > |-+- policy='round-robin 0' prio=-1 status=enabled
> >
> > | |- 6:0:1:5 sdy   65:128 failed undef  running
> >
> > | `- 7:0:0:5 sdz   65:144 failed undef  running
> >
> > `-+- policy='round-robin 0' prio=-1 status=enabled
> >
> >   |- 6:0:0:5 sdx   65:112 failed undef  running
> >
> >   `- 7:0:1:5 sdaa  65:160 failed undef  running
> >
> >
> > Like I said, this only happens on volumes that have been extended past
> 64G.
> > Smaller sizes to not have this issue. I can only assume that the original
> > lun is getting destroyed after the clone process and that is cause of the
> > failed state. Why is it not picking up the new one and attaching it to
> the
> > compute node?  Is there something I am missing?
> >
> > Thanks in advance,
> >
> > Adam
>
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [glance] docs: architecture or hw_architecture

[Dean Troyer]

On Wed, Aug 23, 2017 at 12:33 PM, Brian Rosmaita
 wrote:
> My point is just that Glance went one way on this, Nova went a
> different way, and users are left hanging.  My secondary point is that
> it might be useful to catalog these things in the metadata definitions
> service so that we all stay on the same page better.

This is a great example of why attributes that are actually used
elsewhere should be defined in the API rather than just picked out of
a collection of metadata/properties.

dt

-- 

Dean Troyer
dtro...@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] openstack/openstackclient vs openstack/python-openstackclient

[Dean Troyer]

On Wed, Aug 23, 2017 at 12:39 PM, David Medberry  wrote:
> What's the relationship between
>
> openstack/openstackclient

A meta-package that depends on python-openstackclient and all of the
known (registered with OSC) plugin packages.  This will get you
_everything_ that we know about, but may pull in dependencies that are
unneeded for many users.

> and
>
> openstack/python-openstackclient

A package that includes the commands for Compute, Identity, Image,
Object Store and Volume.  All others are plugins in separate packages.

The 'openstackclient' package has not been released yet, the current
plan is to make its first release when OSC 4 (next major release) is
released.

dt

-- 

Dean Troyer
dtro...@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] [ironic][docs] I see, you see, we all see red*

[Andreas Jaeger]

On 2017-08-23 18:30,  Loo, Ruby  wrote:
> Hi,
> 
>  
> 
> I was brought up to think that red was one of those colours that people
> had different (and sometimes really negative) associations with. When I
> look at our latest and greatest! ironic documentation (e.g. [1]), I see
> red. Not only do I see red, but the term has a different background
> colour and is bordered (or whatever it is called). Are we using the
> wrong .rst syntax, should we be highlighting terms differently? And/or
> is there some way to change the appearance of highlighted terms? I much
> prefer something simple, like bold black text in some uniform font. On
> the other hand, perhaps lots of others like this and I'm in the minority.
> 

Looking at your source code, your html, and at
https://docs.openstack.org/contributor-guide/rst-conv/inline-markups.html
- the red is the expected color by the openstackdocstheme.

See also https://docs.openstack.org/openstackdocstheme/latest/


> I can handle the Warnings that are in red though. (I'm not sure it is
> necesary, given that it is all in a BOX with a WARNING SYMBOL.)
> 
>  
> 
> I hesitated about sending this due to the wonderful bike shedding that
> could happen, don't disappoint me, cuz I'm sure we all have opinions
> about colour. :)

Sure, we all have opinions. I think the best way to avoid a bike shed is
a change that proposes a better colouring scheme. Even is red there
since the beginning of the theme - so now for 2.5 years - the docs team
takes changes to have less colour issues ;)

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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-operators] cinder/nova issues

[Sean McGinnis]

Hey Adam,

There have been some updates since Liberty to improve handling in the os-brick
library that handles the local device management. But with this showing the
paths down, I wonder if there's something else going on there between the
NetApp box and the Nova compute host.

Could you file a bug to track this? I think you could just copy and paste the
content of your original email since it captures a lot of great info.

https://bugs.launchpad.net/cinder/+filebug

We can tag it with netapp so maybe it will get some attention there.

Thanks,
Sean

On Wed, Aug 23, 2017 at 01:01:24PM -0400, Adam Dibiase wrote:
> Greetings,
> 
> I am having an issue with nova starting an instance that is using a root
> volume that cinder has extended. More specifically, a volume that has been
> extended past the max resize limit of our Netapp filer. I am running
> Liberty and upgraded cinder packages to 7.0.3 from 7.0.0 to take advantage
> of this functionality. From what I can gather, it uses sub-lun cloning to
> get past the hard limit set by Netapp when cloning past 64G (starting from
> a 4G volume).
> 
> *Environment*:
> 
>- Release: Liberty
>- Filer:   Netapp
>- Protocol: Fiberchannel
>- Multipath: yes
> 
> 
> 
> *Steps to reproduce: *
> 
>- Create new instance
>- stop instance
>- extend the volume by running the following commands:
>   - cinder reset-state --state available (volume-ID or name)
>   - cinder extend (volume-ID or name) 100
>   - cinder reset-state --state in-use (volume-ID or name)
>- start instance with either nova start or nova reboot --hard  --same
>result
> 
> 
> I can see that the instance's multipath status is good before the resize...
> 
> *360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *
> 
> size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
> 
> |-+- policy='round-robin 0' prio=-1 status=active
> 
> | |- 6:0:1:5 sdy   65:128 active undef  running
> 
> | `- 7:0:0:5 sdz   65:144 active undef  running
> 
> `-+- policy='round-robin 0' prio=-1 status=enabled
> 
>   |- 6:0:0:5 sdx   65:112 active undef  running
> 
>   `- 7:0:1:5 sdaa  65:160 active undef  running
> 
> 
> Once the volume is resized, the lun goes to a failed state and it does not
> show the new size:
> 
> 
> *360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *
> 
> size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
> 
> |-+- policy='round-robin 0' prio=-1 status=enabled
> 
> | |- 6:0:1:5 sdy   65:128 failed undef  running
> 
> | `- 7:0:0:5 sdz   65:144 failed undef  running
> 
> `-+- policy='round-robin 0' prio=-1 status=enabled
> 
>   |- 6:0:0:5 sdx   65:112 failed undef  running
> 
>   `- 7:0:1:5 sdaa  65:160 failed undef  running
> 
> 
> Like I said, this only happens on volumes that have been extended past 64G.
> Smaller sizes to not have this issue. I can only assume that the original
> lun is getting destroyed after the clone process and that is cause of the
> failed state. Why is it not picking up the new one and attaching it to the
> compute node?  Is there something I am missing?
> 
> Thanks in advance,
> 
> Adam

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


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

[openstack-dev] [ptls][ptg] Team Photos are Back!

[Kendall Nelson]

Hello PTL's,

At the PTG we will again have team photos! We are thinking about bringing
props this time too so that when I ask if you want to do a silly one its
less awkward ;)

*The signup period will close the Monday of the PTG (September 11th)* so
make sure to sign up by then if you want team photos. Available time slots
are on both Tuesday and Wednesday. [1]


-Kendall Nelson (diablo_rojo)

[1]
https://docs.google.com/spreadsheets/d/18DmI9ydq6dKr4hAcoAN83vYXWn8TV1NEvy09Ll02_Y0/edit?usp=sharing
__
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] openstack/openstackclient vs openstack/python-openstackclient

[David Medberry]

What's the relationship between

openstack/openstackclient

and

openstack/python-openstackclient

(the first appears to depend upon the latter but I can't ken much more than
that.)
__
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] [glance] docs: architecture or hw_architecture

[Brian Rosmaita]

On Wed, Aug 23, 2017 at 10:54 AM, Markus Zoeller
 wrote:
> On 23.08.2017 14:47, Brian Rosmaita wrote:
>> 'architecture' is one of the "common image properties" that was
>> introduced in Folsom in an effort to standardize use of image
>> metadata.  It's not a mistake in the Glance docs, it's just that Nova
>> is looking for a differently named property.
>>
>> Glance has had a metadata definitions service [0,1] since Juno.  It
>> provides a common API for vendors, admins, services, and users to
>> meaningfully define available key / value pair metadata that can be
>> used on different types of resources (images, artifacts, volumes,
>> flavors, aggregates, and other resources). A definition includes a
>> property’s key, its description, its constraints, and the resource
>> types to which it can be associated.  It's probably a better place to
>> store this kind of information than in documentation.  I think it's
>> under-utilized.
>>
>> [0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html
>> [1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html
>
>
> OK, I agree that the information to do it right is available:
>
> "The keys have different prefixes on images than on flavors.
> On flavors keys are prefixed with hw:, but on images the keys
> are prefixed with hw_."
>
> It's just not *that* easy to find and to deduct. I was looking for that
> information as an operator, to allow the Nova scheduler to do its work
> in a mixed arch environment (x86 + s390x) based on image properties.
>
> I still don't fully get it. In which use-case is `architecture` the
> correct property to set?

It depends on what you mean by "correct". If you're just describing
what's in the image, it works fine.  If you expect it to actually do
something, then you need to use the hw_ one.

My point is just that Glance went one way on this, Nova went a
different way, and users are left hanging.  My secondary point is that
it might be useful to catalog these things in the metadata definitions
service so that we all stay on the same page better.

cheers,
brian

> Regards, Markus Zoeller (markus_z)
>
>> On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller
>>  wrote:
>>> On 22.08.2017 17:10, Markus Zoeller wrote:
 I'm wondering if there is an issue in the docs which describe the
 possible image metadata properties:
 https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#

 This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
 but the Nova scheduler image properties filter uses `hw_architecture`
 (note the *hw_* prefix):
 https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44

 Is that simply a mistake in the Glance docs or do I miss some kind of
 conversion between those metadata keys?

>>>
>>> Looks like only `hw_architecture` works in my x86 + s390x environment.
>>> I'm going to push an update to the Glance docs + an update to the
>>> `os_image` Ansible module which uses `cpu_arch` in its documentation:
>>> http://docs.ansible.com/ansible/latest/os_image_module.html
>>>
>>> --
>>> Regards, Markus Zoeller (markus_z)
>>>
>>>
>
>
> __
> 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] [nova] Thanks gibi!

[David Medberry]

and now recommended for Core too, quite the feat of accomplishments
(resting on the solid work!)

On Fri, Aug 11, 2017 at 1:40 AM, Balazs Gibizer  wrote:

> On Thu, Aug 10, 2017 at 8:43 PM, Jay Pipes  wrote:
>
>> On 08/10/2017 01:57 PM, Matt Riedemann wrote:
>> > Apparently we don't have community contributor awards at the PTG, only
>> > the summit, and seeing as that's several months away now, which is kind
>> > of an eternity, I wanted to take the time now to thank gibi (Balazs
>> > Gibizer to his parents) for all the work he's been doing in Nova.
>> >
>> > Not only does gibi lead the versioned notification transformation work,
>> > which includes running a weekly meeting (that only one other person
>> > shows up to) and sending a weekly status email, and does it in a
>> > ridiculously patient and kind way, but he's also been identifying
>> > several critical issues late in the release related to the Placement and
>> > claims in the scheduler work that's going on.
>> >
>> > And it's not just doing manual testing, reporting a bug and throwing it
>> > over the wall - which is a major feat in OpenStack on it's own - but
>> > also taking the time to write automated functional regression tests to
>> > exhibit the bugs so when we have a fix we can tell it's actually
>> > working, plus he's been fixing some on his own also.
>> >
>> > So with all that, I just wanted to formally and publicly say thanks to
>> > gibi for the great work he's doing which often goes overlooked when
>> > we're crunching toward a deadline.
>>
>> Couldn't agree more. Thank you Gibi for your hard work and valuable
>> contributions over the last cycle and more. Your efforts have not gone
>> unnoticed.
>>
>
> Thank you guys for the nice words, the support, and the encouragement. I
> enjoy working with the community. So I'm planning to continue sending those
> bug reports in the future too.
>
> Cheers,
> gibi
>
>
>
>
>> All the best,
>> -jay
>>
>> 
>> __
>> 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
>
__
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] [murano] murano-dashboard 4.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for murano-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/murano-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/murano-dashboard/log/?h=stable/pike

Release notes for murano-dashboard can be found at:

http://docs.openstack.org/releasenotes/murano-dashboard/




__
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] [murano] murano 4.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for murano for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/murano/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/murano/log/?h=stable/pike

Release notes for murano can be found at:

http://docs.openstack.org/releasenotes/murano/




__
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-operators] cinder/nova issues

[Adam Dibiase]

Greetings,

I am having an issue with nova starting an instance that is using a root
volume that cinder has extended. More specifically, a volume that has been
extended past the max resize limit of our Netapp filer. I am running
Liberty and upgraded cinder packages to 7.0.3 from 7.0.0 to take advantage
of this functionality. From what I can gather, it uses sub-lun cloning to
get past the hard limit set by Netapp when cloning past 64G (starting from
a 4G volume).

*Environment*:

   - Release: Liberty
   - Filer:   Netapp
   - Protocol: Fiberchannel
   - Multipath: yes



*Steps to reproduce: *

   - Create new instance
   - stop instance
   - extend the volume by running the following commands:
  - cinder reset-state --state available (volume-ID or name)
  - cinder extend (volume-ID or name) 100
  - cinder reset-state --state in-use (volume-ID or name)
   - start instance with either nova start or nova reboot --hard  --same
   result


I can see that the instance's multipath status is good before the resize...

*360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *

size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw

|-+- policy='round-robin 0' prio=-1 status=active

| |- 6:0:1:5 sdy   65:128 active undef  running

| `- 7:0:0:5 sdz   65:144 active undef  running

`-+- policy='round-robin 0' prio=-1 status=enabled

  |- 6:0:0:5 sdx   65:112 active undef  running

  `- 7:0:1:5 sdaa  65:160 active undef  running


Once the volume is resized, the lun goes to a failed state and it does not
show the new size:


*360a98000417643556a2b496d58665473 dm-17 NETAPP  ,LUN *

size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw

|-+- policy='round-robin 0' prio=-1 status=enabled

| |- 6:0:1:5 sdy   65:128 failed undef  running

| `- 7:0:0:5 sdz   65:144 failed undef  running

`-+- policy='round-robin 0' prio=-1 status=enabled

  |- 6:0:0:5 sdx   65:112 failed undef  running

  `- 7:0:1:5 sdaa  65:160 failed undef  running


Like I said, this only happens on volumes that have been extended past 64G.
Smaller sizes to not have this issue. I can only assume that the original
lun is getting destroyed after the clone process and that is cause of the
failed state. Why is it not picking up the new one and attaching it to the
compute node?  Is there something I am missing?

Thanks in advance,

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

[openstack-dev] [ironic][docs] I see, you see, we all see red*

[Loo, Ruby]

Hi,

I was brought up to think that red was one of those colours that people had 
different (and sometimes really negative) associations with. When I look at our 
latest and greatest! ironic documentation (e.g. [1]), I see red. Not only do I 
see red, but the term has a different background colour and is bordered (or 
whatever it is called). Are we using the wrong .rst syntax, should we be 
highlighting terms differently? And/or is there some way to change the 
appearance of highlighted terms? I much prefer something simple, like bold 
black text in some uniform font. On the other hand, perhaps lots of others like 
this and I'm in the minority.

I can handle the Warnings that are in red though. (I'm not sure it is necesary, 
given that it is all in a BOX with a WARNING SYMBOL.)

I hesitated about sending this due to the wonderful bike shedding that could 
happen, don't disappoint me, cuz I'm sure we all have opinions about colour. :)

Also, this email thread isn't about discussing the green and orange colours 
used for the code blocks; feel free to start your own thread about that if you 
want!

Thanks for listening,
--ruby

*unless you're colour blind

[1] https://docs.openstack.org/ironic/latest/install/enabling-drivers.html
__
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] [nova] Proposing Balazs Gibizer for nova-core

[Ken'ichi Ohmichi]

Yay (^_^)



2017-08-22 18:18 GMT-07:00 Matt Riedemann :
> I'm proposing that we add gibi to the nova core team. He's been around for
> awhile now and has shown persistence and leadership in the multi-release
> versioned notifications effort, which also included helping new contributors
> to Nova get involved which helps grow our contributor base.
>
> Beyond that though, gibi has a good understanding of several areas of Nova,
> gives thoughtful reviews and feedback, which includes -1s on changes to get
> them in shape before a core reviewer gets to them, something I really value
> and look for in people doing reviews who aren't yet on the core team. He's
> also really helpful with not only reporting and triaging bugs, but writing
> tests to recreate bugs so we know when they are fixed, and also works on
> fixing them - something I expect from a core maintainer of the project.
>
> So to the existing core team members, please respond with a yay/nay and
> after about a week or so we should have a decision (knowing a few cores are
> on vacation right now).
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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-dev] [tricircle-Problem accessing the instance console]

[meher.hihi]

Hello to the Tricircle community,

I am sending you this mail in order to ask for help concerning the launch of 
the console of the instances created in the different regions.

I have two regions each with an active instance and its status is "running", 
for the first region, I can not open the console from the dashboard and for the 
second, the console is displayed but with an error of connection to the server.
PS: access to both console worked without problems before I restarted my server.

Thank you in advance for your help.

Best regards,

Meher

(+33) 7 58 38 68 87

[Logo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] transfer of IP address between ports

[공용준]

Hi Volodymyr

From my understanding, Do you need to maintain same IP address between port(and 
Mac will be changed)?
If that, it will be hard because there’s some cool down time(something like 
reuse ip timeout)  in the neutron IPAM db. If my memory is right, it was ten or 
five sec.  

Actually, I’m using the same kind of scenario here( same ip address to 
different neutron port)
I changed neutron db schema so it can assign same ip address to different port 
( I also changed the neutron policy. only admin can use this function)
In this scenario, 
If i need to have a new port with the previous IP, 
I just create new port with the same IP. and I use this function to achieve the 
ECMP in our cloud. 

Regards, 
Andrew

> 2017. 8. 23. 오후 11:30, Volodymyr Litovka  작성:
> 
> Hi Andrew,
> 
> thanks for the prompt reply.
> 
> I'm using fixed ip addresses, not floating IPs. In terms of Heat it looks 
> like there:
> 
> n1-wan:
>   type: OS::Neutron::Port
>   properties:
> name: n1-wan
> network: e-net
> fixed_ips: [ { subnet: e-subnet, ip_address: X.X.X.X } ]
> 
> n1:
>   type: OS::Nova::Server
>   properties:
> name: n1
> networks:
>   - port: { get_resource: n1-wan }
> 
> and there are some constraints in my installation:
> 
> I can't move ports between VMs (in order to support predictable naming 
> according to port roles, their MAC addresses are stored in udev rules inside 
> VM and if I will change port, rules/roles will fail)
> I don't want to use floating ip due to possible performance degradation when 
> using massive NAT
> Another idea I have is to move ports between VMs, changing their MACs 
> accordingly and will try it if no other ways will be found :)
> 
> Thanks again.
> 
> On 8/23/17 5:17 PM, 공용준 wrote:
>> Hi
>> 
>> You can use fixed ip port for this. 
>> create neutron port and attach it to the one vm. 
>> or 
>> you can use floating ip for this purpose as well 
>> 
>> Regards, 
>> Andrew
>>  
>>> 2017. 8. 23. 오후 10:58, Volodymyr Litovka >> > 작성:
>>> 
>>> Hi colleagues,
>>> 
>>> imagine, somebody (e.g. me :-) ) needs to transfer IP address between two 
>>> ports. The straight way is: release IP address and then assign it to 
>>> another port.
>>> 
>>> The possible problem with this way is time between release and assignment - 
>>> during this time, this IP address is in DHCP pool and can be automatically 
>>> assigned to some another port upon request.
>>> 
>>> Any ideas how to prevent leasing this IP address during this time?
>>> 
>>> Thank you.
>>> -- 
>>> Volodymyr Litovka
>>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>> ___
>>> 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 
>>> 
>> 
> 
> -- 
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison

___
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] [glance] docs: architecture or hw_architecture

[Markus Zoeller]

On 23.08.2017 14:47, Brian Rosmaita wrote:
> 'architecture' is one of the "common image properties" that was
> introduced in Folsom in an effort to standardize use of image
> metadata.  It's not a mistake in the Glance docs, it's just that Nova
> is looking for a differently named property.
> 
> Glance has had a metadata definitions service [0,1] since Juno.  It
> provides a common API for vendors, admins, services, and users to
> meaningfully define available key / value pair metadata that can be
> used on different types of resources (images, artifacts, volumes,
> flavors, aggregates, and other resources). A definition includes a
> property’s key, its description, its constraints, and the resource
> types to which it can be associated.  It's probably a better place to
> store this kind of information than in documentation.  I think it's
> under-utilized.
> 
> [0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html
> [1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html


OK, I agree that the information to do it right is available:

"The keys have different prefixes on images than on flavors.
On flavors keys are prefixed with hw:, but on images the keys
are prefixed with hw_."

It's just not *that* easy to find and to deduct. I was looking for that
information as an operator, to allow the Nova scheduler to do its work
in a mixed arch environment (x86 + s390x) based on image properties.

I still don't fully get it. In which use-case is `architecture` the
correct property to set?

-- 
Regards, Markus Zoeller (markus_z)

> On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller
>  wrote:
>> On 22.08.2017 17:10, Markus Zoeller wrote:
>>> I'm wondering if there is an issue in the docs which describe the
>>> possible image metadata properties:
>>> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#
>>>
>>> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
>>> but the Nova scheduler image properties filter uses `hw_architecture`
>>> (note the *hw_* prefix):
>>> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44
>>>
>>> Is that simply a mistake in the Glance docs or do I miss some kind of
>>> conversion between those metadata keys?
>>>
>>
>> Looks like only `hw_architecture` works in my x86 + s390x environment.
>> I'm going to push an update to the Glance docs + an update to the
>> `os_image` Ansible module which uses `cpu_arch` in its documentation:
>> http://docs.ansible.com/ansible/latest/os_image_module.html
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>
>>


__
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] transfer of IP address between ports

[Volodymyr Litovka]

Hi Andrew,

thanks for the prompt reply.

I'm using fixed ip addresses, not floating IPs. In terms of Heat it 
looks like there:


n1-wan:
  type: OS::Neutron::Port
  properties:
    name: n1-wan
    network: e-net
    fixed_ips: [ { subnet: e-subnet, ip_address: X.X.X.X } ]

n1:
  type: OS::Nova::Server
  properties:
    name: n1
    networks:
  - port: { get_resource: n1-wan }

and there are some constraints in my installation:

1. I can't move ports between VMs (in order to support predictable
   naming according to port roles, their MAC addresses are stored in
   udev rules inside VM and if I will change port, rules/roles will fail)
2. I don't want to use floating ip due to possible performance
   degradation when using massive NAT

Another idea I have is to move ports between VMs, changing their MACs 
accordingly and will try it if no other ways will be found :)


Thanks again.

On 8/23/17 5:17 PM, 공용준 wrote:

Hi

You can use fixed ip port for this.
create neutron port and attach it to the one vm.
or
you can use floating ip for this purpose as well

Regards,
Andrew
2017. 8. 23. 오후 10:58, Volodymyr Litovka > 작성:


Hi colleagues,

imagine, somebody (e.g. me :-) ) needs to transfer IP address between 
two ports. The straight way is: release IP address and then assign it 
to another port.


The possible problem with this way is time between release and 
assignment - during this time, this IP address is in DHCP pool and 
can be automatically assigned to some another port upon request.


Any ideas how to prevent leasing this IP address during this time?

Thank you.

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison
___
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




--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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] transfer of IP address between ports

[Kevin Benton]

If re-using the port isn't feasible. You can update the allocation pools on
the subnet to exclude the IP address in question. It's hacky, but doing
that before removing it from the original port will ensure it's not
automatically allocated to another port.

On Wed, Aug 23, 2017 at 8:17 AM, 공용준  wrote:

> Hi
>
> You can use fixed ip port for this.
> create neutron port and attach it to the one vm.
> or
> you can use floating ip for this purpose as well
>
> Regards,
> Andrew
>
>
> 2017. 8. 23. 오후 10:58, Volodymyr Litovka  작성:
>
> Hi colleagues,
>
> imagine, somebody (e.g. me :-) ) needs to transfer IP address between two
> ports. The straight way is: release IP address and then assign it to
> another port.
>
> The possible problem with this way is time between release and assignment
> - during this time, this IP address is in DHCP pool and can be
> automatically assigned to some another port upon request.
>
> Any ideas how to prevent leasing this IP address during this time?
>
> Thank you.
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
> ___
> 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

[openstack-dev] [docs] Documentation meeting Thursday

[Petr Kovar]

Hi all,

The docs meeting will continue tomorrow, Thursday at 16:00 UTC in
#openstack-meeting, as scheduled. For more details, and the agenda, see the
meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] transfer of IP address between ports

[공용준]

Hi

You can use fixed ip port for this. 
create neutron port and attach it to the one vm. 
or 
you can use floating ip for this purpose as well 

Regards, 
Andrew
 
> 2017. 8. 23. 오후 10:58, Volodymyr Litovka  작성:
> 
> Hi colleagues,
> 
> imagine, somebody (e.g. me :-) ) needs to transfer IP address between two 
> ports. The straight way is: release IP address and then assign it to another 
> port.
> 
> The possible problem with this way is time between release and assignment - 
> during this time, this IP address is in DHCP pool and can be automatically 
> assigned to some another port upon request.
> 
> Any ideas how to prevent leasing this IP address during this time?
> 
> Thank you.
> -- 
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
> ___
> 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] transfer of IP address between ports

[Volodymyr Litovka]

Hi colleagues,

imagine, somebody (e.g. me :-) ) needs to transfer IP address between 
two ports. The straight way is: release IP address and then assign it to 
another port.


The possible problem with this way is time between release and 
assignment - during this time, this IP address is in DHCP pool and can 
be automatically assigned to some another port upon request.


Any ideas how to prevent leasing this IP address during this time?

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
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] [openstack][oslo][all] Clean up oslo deprecated stuff !

[Amrith Kumar]

GCB, Ken, thanks for doing this. It will help immensely.


-amrith



On Wed, Aug 23, 2017 at 9:32 AM, Ken Giusti  wrote:

>
>
> On Tue, Aug 22, 2017 at 3:24 AM, ChangBo Guo  wrote:
>
>> Hi ALL,
>>
>> We discussed a little about how to avoid breaking consuming projects'
>> gate in oslo weekly meeting last week.  The easy improvement is that clean
>> up deprecated stuff in oslo at the beginning of Queens.  I collected
>> deprecated stuff  in [1].  This need Oslo team and other team work
>> toghether. I think we can start the work when cycle Queens is open. I
>> also reserved a room in PTG
>> for 2 hours to do hacking.[2]
>>
>>
>> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
>> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>>
>> --
>> ChangBo Guo(gcb)
>>
>> 
>> __
>> 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
>>
>>
> I've gone through oslo.messaging and have updated the etherpad [1] with a
> few more entries.  I've opened launchpad bugs where appropriate, adding the
> oslo-debt-cleanup tag to each for good measure.
>
> The original list included a few items that as best I can tell were not
> tagged as deprecated via debtcollector until Pike. IIUC we can't remove
> those in Queens, correct?
>
> --
> Ken Giusti  (kgiu...@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
>
>
__
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] [nova] Proposing Balazs Gibizer for nova-core

[Kevin L. Mitchell]

On Tue, 2017-08-22 at 20:18 -0500, Matt Riedemann wrote:
> I'm proposing that we add gibi to the nova core team. He's been around 
> for awhile now and has shown persistence and leadership in the 
> multi-release versioned notifications effort, which also included 
> helping new contributors to Nova get involved which helps grow our 
> contributor base.

+1 from me
-- 
Kevin L. Mitchell 

signature.asc
Description: This is a digitally signed message part
__
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] [sahara] Sahara PTG Schedule

[Telles Nobrega]

Hi folks,

I've just finished a first version of Sahara schedule for Queens PTG. I
encourage all of the interested to take a look and make suggestions.

Best regards,
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
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] Team dinner at the PTG?

[Dmitry Tantsur]

Hi folks!

We're trying to organize an informal team meeting at some place, probably with 
burgers and beer, in Denver. Note that it won't be sponsored.


Please vote in the Doodle https://doodle.com/poll/nvavg9ab9ebq2e4v about the 
days you're available.


If you're local, we need you help finding a good place to go. Please ping Julia 
(TheJulia) or myself (dtantsur) on IRC if you're willing to help.


Thanks,
Dmitry

__
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] [openstack][oslo][all] Clean up oslo deprecated stuff !

[Ken Giusti]

On Tue, Aug 22, 2017 at 3:24 AM, ChangBo Guo  wrote:

> Hi ALL,
>
> We discussed a little about how to avoid breaking consuming projects' gate
> in oslo weekly meeting last week.  The easy improvement is that clean up
> deprecated stuff in oslo at the beginning of Queens.  I collected
> deprecated stuff  in [1].  This need Oslo team and other team work
> toghether. I think we can start the work when cycle Queens is open. I
> also reserved a room in PTG
> for 2 hours to do hacking.[2]
>
>
> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>
> --
> ChangBo Guo(gcb)
>
> __
> 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
>
>
I've gone through oslo.messaging and have updated the etherpad [1] with a
few more entries.  I've opened launchpad bugs where appropriate, adding the
oslo-debt-cleanup tag to each for good measure.

The original list included a few items that as best I can tell were not
tagged as deprecated via debtcollector until Pike. IIUC we can't remove
those in Queens, correct?

-- 
Ken Giusti  (kgiu...@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] Redhat overcloud deployment failing at post deployment step

[Vagner Farias]

Hello Shyam,

As a general rule, I'd recommend using the following command to investigate
deployment failures (after sourcing stackrc file). Send back the results to
the list if the output still seems confusing.

$ openstack stack failures list --long overcloud

It'd also help the investigation if you could make the
storage-environment.yaml and network-environment.yaml files available,
together with the results of above command  (http://paste.openstack.org/ or
somewhere else).

AllNodesDeploySteps is a huge stack with several nested stacks and the
failure could have happened in any of the steps. Although the above command
should provide a clue of what happened, if you are curious you may like to
run the command below to list all the nested resources:

$ openstack stack resource list -n5

or, to get only the failed resources:

$ openstack stack resource list -n5 | grep FAIL

There a good explanation on how to debug tripleo heat templates at
http://hardysteven.blogspot.com.br/2015/04/debugging-tripleo-heat-templates.html,
if you want to go further.

-- 
Vagner Farias


On Wed, Aug 23, 2017 at 3:30 AM, Shyam Biradar  wrote:

> Hi,
>
>
> I am installing Redhat openstack platform 10 on virtual environment (KVM)
> using pxe_ssh ipmi driver.
> Undercloud, compute, controller all three nodes are available on single
> kvm box. Using single nic config.
>
> Overcloud deployment failing during post deployement step with following
> error:
> ---
> 017-08-22 13:42:55Z 
> [overcloud.AllNodesDeploySteps.ControllerDeployment_Step4]:
> CREATE_FAILED  Resource CREATE failed: Error: resources[0]: Deployment to
> server failed: deploy_status_code : Deployment exited with non-zero status
> code: 6
>
>
> ---
>
> Corresponding heat resource is
>
> -
> [stack@redhat-undercloud ~]$ openstack stack resource list overcloud |
> grep FAILED
> | AllNodesDeploySteps   | 
> 186d4a53-e171-4184-a8e2-4f5fbc1290ee
> | OS::TripleO::PostDeploySteps| CREATE_FAILED
> | 2017-08-22T13:13:47Z |
> [stack@redhat-undercloud ~]$
> 
>
>
>
> I am using following command to deploy overcloud:
> 
>
> openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-
> heat-templates/environments/network-isolation.yaml \
> -e ~/templates/network-environment.yaml \
> -e ~/templates/storage-environment.yaml \
> --control-scale 1 --compute-scale 1 --control-flavor control
> --compute-flavor compute \
> --ntp-server 0.north-america.pool.ntp.org --neutron-network-type vxlan
> --neutron-tunnel-types vxlan \
> --validation-errors-fatal --validation-warnings-fatal --timeout 90
> -
>
>
> No errors I could find in os-collect-config or heat logs except following:
>
> Aug 22 23:52:03 localhost os-collect-config: 
> /var/lib/os-collect-config/local-data
> not found. Skipping
> Aug 22 23:52:03 localhost os-collect-config: No local metadata found
> (['/var/lib/os-collect-config/local-data'])
>
>
> I have looked into /var/log/heat/*, os-collect-config logs. Any other log
> files that I should look into?
>
>
> Thanks & Regards,
> Shyam Biradar,
> Email: shyambiradarsgg...@gmail.com,
> Contact: +91 8600266938 <+91%2086002%2066938>.
>
> ___
> 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] [glance] docs: architecture or hw_architecture

[Brian Rosmaita]

'architecture' is one of the "common image properties" that was
introduced in Folsom in an effort to standardize use of image
metadata.  It's not a mistake in the Glance docs, it's just that Nova
is looking for a differently named property.

Glance has had a metadata definitions service [0,1] since Juno.  It
provides a common API for vendors, admins, services, and users to
meaningfully define available key / value pair metadata that can be
used on different types of resources (images, artifacts, volumes,
flavors, aggregates, and other resources). A definition includes a
property’s key, its description, its constraints, and the resource
types to which it can be associated.  It's probably a better place to
store this kind of information than in documentation.  I think it's
under-utilized.

[0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html
[1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html

On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller
 wrote:
> On 22.08.2017 17:10, Markus Zoeller wrote:
>> I'm wondering if there is an issue in the docs which describe the
>> possible image metadata properties:
>> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#
>>
>> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
>> but the Nova scheduler image properties filter uses `hw_architecture`
>> (note the *hw_* prefix):
>> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44
>>
>> Is that simply a mistake in the Glance docs or do I miss some kind of
>> conversion between those metadata keys?
>>
>
> Looks like only `hw_architecture` works in my x86 + s390x environment.
> I'm going to push an update to the Glance docs + an update to the
> `os_image` Ansible module which uses `cpu_arch` in its documentation:
> http://docs.ansible.com/ansible/latest/os_image_module.html
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> 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-dev] [acceleration]Cyborg Weekly Team Meeting Aug 23th

[Zhipeng Huang]

Hi team,

We will as usual have our team meeting today UTC 1500 at #openstack-cyborg,
initial agenda at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [nova] Proposing Balazs Gibizer for nova-core

[Jay Pipes]

+1

On 08/22/2017 09:18 PM, Matt Riedemann wrote:
I'm proposing that we add gibi to the nova core team. He's been around 
for awhile now and has shown persistence and leadership in the 
multi-release versioned notifications effort, which also included 
helping new contributors to Nova get involved which helps grow our 
contributor base.


Beyond that though, gibi has a good understanding of several areas of 
Nova, gives thoughtful reviews and feedback, which includes -1s on 
changes to get them in shape before a core reviewer gets to them, 
something I really value and look for in people doing reviews who aren't 
yet on the core team. He's also really helpful with not only reporting 
and triaging bugs, but writing tests to recreate bugs so we know when 
they are fixed, and also works on fixing them - something I expect from 
a core maintainer of the project.


So to the existing core team members, please respond with a yay/nay and 
after about a week or so we should have a decision (knowing a few cores 
are on vacation right now).




__
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] [nova] Proposing Balazs Gibizer for nova-core

[Juan Antonio Osorio]

Nice!! Congrats Gibi!!

On 23 Aug 2017 11:19, "Stephen Finucane"  wrote:

> On Tue, 2017-08-22 at 20:18 -0500, Matt Riedemann wrote:
> > I'm proposing that we add gibi to the nova core team. He's been around
> > for awhile now and has shown persistence and leadership in the
> > multi-release versioned notifications effort, which also included
> > helping new contributors to Nova get involved which helps grow our
> > contributor base.
> >
> > Beyond that though, gibi has a good understanding of several areas of
> > Nova, gives thoughtful reviews and feedback, which includes -1s on
> > changes to get them in shape before a core reviewer gets to them,
> > something I really value and look for in people doing reviews who aren't
> > yet on the core team. He's also really helpful with not only reporting
> > and triaging bugs, but writing tests to recreate bugs so we know when
> > they are fixed, and also works on fixing them - something I expect from
> > a core maintainer of the project.
> >
> > So to the existing core team members, please respond with a yay/nay and
> > after about a week or so we should have a decision (knowing a few cores
> > are on vacation right now).
>
> Yay, for sure.
>
> Stephen
>
> __
> 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] [glance] docs: architecture or hw_architecture

[Markus Zoeller]

On 22.08.2017 17:10, Markus Zoeller wrote:
> I'm wondering if there is an issue in the docs which describe the
> possible image metadata properties:
> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#
> 
> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
> but the Nova scheduler image properties filter uses `hw_architecture`
> (note the *hw_* prefix):
> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44
> 
> Is that simply a mistake in the Glance docs or do I miss some kind of
> conversion between those metadata keys?
> 

Looks like only `hw_architecture` works in my x86 + s390x environment.
I'm going to push an update to the Glance docs + an update to the
`os_image` Ansible module which uses `cpu_arch` in its documentation:
http://docs.ansible.com/ansible/latest/os_image_module.html

-- 
Regards, Markus Zoeller (markus_z)


__
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] [Networking-OVN] Unable to run OVN functional tests

[Numan Siddique]

On Wed, Aug 23, 2017 at 10:41 AM, Trinath Somanchi  wrote:

> I’m not running functional tests as root.
>
>
>
> Also, from [1] , The following errors fails most for the cases.
>
>
>
> Captured pythonlogging:
>
> ~~~
>
>ERROR [neutron.agent.linux.utils] Exit code: 1; Stdin: ; Stdout: ;
> Stderr: 2017-08-19T19:16:26Z|1|unixctl|WARN|failed to connect to
> /tmp/tmpNpVzUM/tmpxaCA5
>
> ovs-appctl: cannot connect to "/tmp/tmpNpVzUM/tmpxaCA5m/ovnnb_db.ctl"
> (No such file or directory)
>
>
>
>ERROR [neutron.agent.linux.utils] Exit code: 1; Stdin: ; Stdout: ;
> Stderr: 2017-08-19T19:16:26Z|1|unixctl|WARN|failed to connect to
> /tmp/tmpNpVzUM/tmpxaCA5
>
> ovs-appctl: cannot connect to "/tmp/tmpNpVzUM/tmpxaCA5m/ovnsb_db.ctl"
> (No such file or directory)
>
>
>
> why the test case is searching ovnnb_db.ctl at some other location?
>
>
You see these error logs when the test calls the "stop" function here [1].
"stop" is called because of [2] as part of cleanup.

The real issue is "utils.create_process(ovsdb_server_cmd)" called here [3]
is failing and you probably need to debug why.

Did you get the chance to try to the commands which I suggested in my
previous email ?


Thanks


[1] -
https://github.com/openstack/networking-ovn/blob/master/networking_ovn/tests/functional/resources/process.py#L125
[2] -
https://github.com/openstack/networking-ovn/blob/master/networking_ovn/tests/functional/resources/process.py#L66
[3] -
https://github.com/openstack/networking-ovn/blob/master/networking_ovn/tests/functional/resources/process.py#L108


>
>
> [1] http://paste.openstack.org/show/618837/
>
>
>
> Best Regards,
>
> Trinath Somanchi | *NXP* | *HSDC*, *INDIA*
>
>
>
> *From:* Numan Siddique [mailto:nusid...@redhat.com]
> *Sent:* Wednesday, August 23, 2017 10:25 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Networking-OVN] Unable to run OVN
> functional tests
>
>
>
>
>
>
>
> On Wed, Aug 23, 2017 at 12:03 AM, Assaf Muller  wrote:
>
>
>
>
>
> On Sat, Aug 19, 2017 at 3:02 PM, Trinath Somanchi <
> trinath.soman...@nxp.com> wrote:
>
> Hi-
>
>
>
> Using [1] I have enabled devstack setup.
>
>
>
> Now that when I try dvsm-functional tests, I get all tests failed.
>
>
>
> Please find the error log [2]  help me resolve this issue.
>
>
>
> Looking into the logs, I am pretty sure there is some problem in finding
>  'ovsdb-server' binary in the path.
>
> May be you need to verify if you have installed the ovs properly in your
> system. I would suggest you clone ovs repository, compile it and run "sudo
> make install".
>
>
>
> Since you have mentioned that you have deployed devstack, devstack ovn
> script should have compiled ovs and installed.
>
> What I suggest you to do is verify again if you have installed ovs
> properly. Run "which ovsdb-server" and see if it returns
> "/usr/local/sbin/ovsdb-server".
>
>
>
> If you see the code here - https://github.com/
> openstack/networking-ovn/blob/master/networking_ovn/tests/
> functional/resources/process.py#L91, it uses 
> spawn.find_executable('ovsdb-server').
> May be you can run "spawn.find_executable('ovsdb-server') this out in a
> python shell.
>
>
>
> I hope you are not running functional tests as "sudo". When you run as
> sudo it may be possible that /usr/local/bin or /usr/local/sbin might not be
> in the PATH environment.
>
>
>
> Thanks
>
> Numan
>
>
>
>
>
> Also, were there any tempests tests possible for OVN?
>
>
>
> The networking-ovn repo doesn't add new Tempest tests, but the Tempest
> networking tests, as well as the Tempest tests in the Neutron tree can be
> run against a cloud using OVN.
>
>
>
>
>
> [1] https://docs.openstack.org/networking-ovn/latest/
> contributor/testing.html
>
> [2] http://paste.openstack.org/show/618837/
>
>
>
>
>
> Best Regards,
>
> */ Trinath Somanchi.*
>
> [image: cid:image001.png@01D28854.B7934C80]
>
> *Trinath Somanchi.*
>
> Hyderabad Software Development Center (HSDC), GSD , DN,
>
> NXP India Pvt Limited, 1st Floor, Block 3, DLF Cyber City, Gachibowli,
>
> Hyderabad, Telangana, 500032, India
>
>
>
> Email: *trinath.soman...@nxp.com *  | Mobile: +91
> 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image002.png@01D28854.B7934C80]
>
>
>
>
>
>
>
>
>
>
> __
> 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
> 

Re: [Openstack] Expected VLAN (not received): Deploy OpenStack Via Fuel

[Mohan Kumar]

Hi ,

Just create storage, management, private VLAN tags in the switch used
between jump host server and fuel nodes. By default configuration, Fuel
master expects 101,102,103 VLAN tag configuration

Thanks.m
Mohankumar.N

On Fri, Aug 18, 2017 at 4:03 AM, Vichord Wong 
wrote:

> Hi All,
>
>
> Greetings!
>
>
> I need some help on deploying OpenStack using Fuel.
>
>
> I tried to install and deploy openstack on three HP servers, each of them
> consists of 1 CPU with 4 physical cores, 16 GB memory, 500G hard disk, and
> one physical NIC
>
> Server 1: install fuel
>
> Server 2: Ubuntu bootstrap --- discovered by fuel and added as a
> controller
>
> Server 3: Ubuntu bootstrap --- discovered by fuel and added as a compute
> node
>
>
> These servers are plugged into Cisco Linksys E2500 Router.
>
>
> When I tried to verify the network it always failed at "Expected VLAN (not
> received)". Inside a table, a bunch of VLAN IDs are listed under "Expected
> VLAN (not received)".
>
> For example: 1024, 1026, 1027,1028, 1029, 1030, 1025, 101, 102, 1000,
> 1001, 1002, 1003, 1004, 1005, 1006,1007, 1008, 1009, 1010, 1011, 1012,
> 1013, 1014, 1015, 1016, 1017, 1018, 1019, 1020, 1021, 1022, 1023.
>
>
> Could you let me know what causes this issue and how I can fix this
> problem?
>
>
> Thanks a lot.
>
>
> Regards,
>
> Song
>
>
>
>
> ___
> 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] [nova] Proposing Balazs Gibizer for nova-core

[Stephen Finucane]

On Tue, 2017-08-22 at 20:18 -0500, Matt Riedemann wrote:
> I'm proposing that we add gibi to the nova core team. He's been around 
> for awhile now and has shown persistence and leadership in the 
> multi-release versioned notifications effort, which also included 
> helping new contributors to Nova get involved which helps grow our 
> contributor base.
> 
> Beyond that though, gibi has a good understanding of several areas of 
> Nova, gives thoughtful reviews and feedback, which includes -1s on 
> changes to get them in shape before a core reviewer gets to them, 
> something I really value and look for in people doing reviews who aren't 
> yet on the core team. He's also really helpful with not only reporting 
> and triaging bugs, but writing tests to recreate bugs so we know when 
> they are fixed, and also works on fixing them - something I expect from 
> a core maintainer of the project.
> 
> So to the existing core team members, please respond with a yay/nay and 
> after about a week or so we should have a decision (knowing a few cores 
> are on vacation right now).

Yay, for sure.

Stephen

__
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]clean failed after I finished clean-step

[王俊]

Hi:
anybody saw this before?http://paste.openstack.org/show/619133/
I typed clean-step to config raid,after that,the node status was in 
manageable,then I made status to provide,the error appeared.
I don’t know how to fixed it

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
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] [openstack][oslo][all] Clean up oslo deprecated stuff !

[Jay Pipes]

On 08/22/2017 08:44 AM, ChangBo Guo wrote:
2017-08-22 20:37 GMT+08:00 Doug Hellmann >:


Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> Hi ALL,
>
> We discussed a little about how to avoid breaking consuming projects' gate
> in oslo weekly meeting last week.  The easy improvement is that clean up
> deprecated stuff in oslo at the beginning of Queens.  I collected
> deprecated stuff  in [1].  This need Oslo team and other team work
> toghether. I think we can start the work when cycle Queens is open. I also
> reserved a room in PTG
> for 2 hours to do hacking.[2]
>
>
> [1] https://etherpad.openstack.org/p/oslo-queens-tasks

> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

>

Cleaning up some of this technical debt is a great idea for Queens!

What do you think about using a common gerrit topic to make those
reviews easy to find across the repository?

   yeah, that's helpful to track the reviews,  what about the topic 
'oslo-debt-cleanup' ?


+1

In oslo.db there's a number of config options that have been marked 
deprecated for many release cycles. The topic of when to remove the 
deprecation warnings came up recently on 
https://review.openstack.org/#/c/334182/.


Would be great to do some of this cleanup in Queens. Thanks for bringing 
the topic up, ChangBo!


Best,
-jay

__
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] [xenserver-ocata] neutron-dhcp/metadata agent on XenServer

[Huan Xie]

Hi Adhi,

Welcome, no need to add physical port to br-int.
We just want to check the DHCP request can be received by DHCP agent.
We met such issue that VM cannot get IP via DHCP, see my blog 
https://www.citrix.com/blogs/2015/10/13/xenserver-debugging-on-vmscannot-get-ip-from-dhcp-agent/
 (seems there are some format issues ,so you can refer this 
https://github.com/Annie-XIE/summary-os/blob/master/test-blog.md) maybe you can 
also check these aspects in the blog.

Thanks,
Huan

From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: Wednesday, August 23, 2017 2:53 PM
To: Huan Xie 
Cc: Bob Ball ; openstack ; 
#OpenStack External Email 
Subject: Re: [Openstack] [xenserver-ocata] neutron-dhcp/metadata agent on 
XenServer

hi Huan,

thanks for your suggest, I'll try again, do I need to add physical port to 
br-int at compute node (dom-U) ?

I'll paste the dhcp logs later.

On Wed, Aug 23, 2017 at 10:46 AM, Huan Xie 
> wrote:
Hi Adhi,
As the link 
https://docs.openstack.org/ocata/networking-guide/config-dhcp-ha.html 
described, we can add DHCP agent in compute node (DomU) and it make sense as 
VMs just get internal fixed IP, so locating the DHCP in compute node should 
work.
If the VM cannot get IP, I suspect maybe the VM’s DHCP request isn’t arrived to 
that DHCP agent, maybe the  so here are some questions:

1.   The agent_scheduler isn’t work for the DHCP agent in Nova compute 
node? Could you give some logs of DHCP agent.

2.   The VM isn’t get correct internal vlan tag? Could you double check 
about the VM’s VIF information in Dom0.

a.   ovs-vsctl show

b.  ovs-ofctl show br-int

c.   ovs-ofctl dump-flows br-int
Thanks,
Huan
From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: Wednesday, August 23, 2017 9:32 AM
To: Bob Ball
Cc: openstack; #OpenStack External Email
Subject: Re: [Openstack] [xenserver-ocata] neutron-dhcp/metadata agent on 
XenServer

hi bob,

yep, yesterday I try to install neutron-dhcp/metadata agent along with 
nova-compute inside of compute node (domU) , the neutron-dhcp/metadata agent 
was working, I see from the log. but instance can't get the IP address from 
dhcp server.

the working scenario now, I made 2 network node, on each network node contain 
L3-Agent, DHCP-agent, and metadata-agent.

On Tue, Aug 22, 2017 at 9:25 PM, Bob Ball 
> wrote:
Hi Adhi,

If the Neutron agents would normally run with the nova compute services, then 
they would need to run in the compute VM when deploying with XenServer, not in 
domain 0.

I would assume that the DHCP agents should also run in the compute VM.

Also added openst...@citrix.com to include others.

Bob

From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: 22 August 2017 06:58
To: openstack 
>
Subject: [Openstack] [xenserver-ocata] neutron-dhcp/metadata agent on XenServer

Hi,
According to this guide:
https://docs.openstack.org/ocata/networking-guide/config-dhcp-ha.html

If I want to add HA on my openstack-xenserver environment , is it possible to 
include neutron-dhcp/metadata agent on Compute-node ?

or I have to add neutron-dhcp/metadata agent on xenserver dom0 ?
or I have to create more neutron-dhcp/metadata agent on separate node ?

--
Cheers,


Adhi Priharmanto
about.me/a_dhi






+62-812-82121584




--
Cheers,


Adhi Priharmanto
about.me/a_dhi






+62-812-82121584




--
Cheers,


Adhi Priharmanto
about.me/a_dhi






+62-812-82121584

___
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] [xenserver-ocata] neutron-dhcp/metadata agent on XenServer

[Adhi Priharmanto]

hi Huan,

thanks for your suggest, I'll try again, do I need to add physical port to
br-int at compute node (dom-U) ?

I'll paste the dhcp logs later.

On Wed, Aug 23, 2017 at 10:46 AM, Huan Xie  wrote:

> Hi Adhi,
>
> As the link https://docs.openstack.org/ocata/networking-guide/config-
> dhcp-ha.html described, we can add DHCP agent in compute node (DomU) and
> it make sense as VMs just get internal fixed IP, so locating the DHCP in
> compute node should work.
>
> If the VM cannot get IP, I suspect maybe the VM’s DHCP request isn’t
> arrived to that DHCP agent, maybe the  so here are some questions:
>
> 1.   The agent_scheduler isn’t work for the DHCP agent in Nova
> compute node? Could you give some logs of DHCP agent.
>
> 2.   The VM isn’t get correct internal vlan tag? Could you double
> check about the VM’s VIF information in Dom0.
>
> a.   ovs-vsctl show
>
> b.  ovs-ofctl show br-int
>
> c.   ovs-ofctl dump-flows br-int
>
> Thanks,
>
> Huan
>
> *From:* Adhi Priharmanto [mailto:adhi@gmail.com]
> *Sent:* Wednesday, August 23, 2017 9:32 AM
> *To:* Bob Ball
> *Cc:* openstack; #OpenStack External Email
> *Subject:* Re: [Openstack] [xenserver-ocata] neutron-dhcp/metadata agent
> on XenServer
>
>
>
> hi bob,
>
>
>
> yep, yesterday I try to install neutron-dhcp/metadata agent along with
> nova-compute inside of compute node (domU) , the neutron-dhcp/metadata
> agent was working, I see from the log. but instance can't get the IP
> address from dhcp server.
>
>
>
> the working scenario now, I made 2 network node, on each network node
> contain L3-Agent, DHCP-agent, and metadata-agent.
>
>
>
> On Tue, Aug 22, 2017 at 9:25 PM, Bob Ball  wrote:
>
> Hi Adhi,
>
>
>
> If the Neutron agents would normally run with the nova compute services,
> then they would need to run in the compute VM when deploying with
> XenServer, not in domain 0.
>
>
>
> I would assume that the DHCP agents should also run in the compute VM.
>
>
>
> Also added openst...@citrix.com to include others.
>
>
>
> Bob
>
>
>
> *From:* Adhi Priharmanto [mailto:adhi@gmail.com]
> *Sent:* 22 August 2017 06:58
> *To:* openstack 
> *Subject:* [Openstack] [xenserver-ocata] neutron-dhcp/metadata agent on
> XenServer
>
>
>
> Hi,
> According to this guide:
>
> https://docs.openstack.org/ocata/networking-guide/config-dhcp-ha.html
>
>
> If I want to add HA on my openstack-xenserver environment , is it possible
> to include neutron-dhcp/metadata agent on Compute-node ?
>
>
>
> or I have to add neutron-dhcp/metadata agent on xenserver dom0 ?
>
> or I have to create more neutron-dhcp/metadata agent on separate node ?
>
>
>
> --
>
> Cheers,
>
>
>
> *Adhi Priharmanto*
>
> about.me/a_dhi
>
>
>
> +62-812-82121584 <+62%20812-8212-1584>
>
>
>
>
>
>
>
> --
>
> Cheers,
>
>
>
> *Adhi Priharmanto*
>
> about.me/a_dhi
>
>
>
> +62-812-82121584 <+62%20812-8212-1584>
>
>
>



-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584
___
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] Redhat overcloud deployment failing at post deployment step

[Shyam Biradar]

Hi,


I am installing Redhat openstack platform 10 on virtual environment (KVM)
using pxe_ssh ipmi driver.
Undercloud, compute, controller all three nodes are available on single kvm
box. Using single nic config.

Overcloud deployment failing during post deployement step with following
error:
---
017-08-22 13:42:55Z
[overcloud.AllNodesDeploySteps.ControllerDeployment_Step4]: CREATE_FAILED
 Resource CREATE failed: Error: resources[0]: Deployment to server failed:
deploy_status_code : Deployment exited with non-zero status code: 6


---

Corresponding heat resource is

-
[stack@redhat-undercloud ~]$ openstack stack resource list overcloud | grep
FAILED
| AllNodesDeploySteps   |
186d4a53-e171-4184-a8e2-4f5fbc1290ee | OS::TripleO::PostDeploySteps
   | CREATE_FAILED   | 2017-08-22T13:13:47Z |
[stack@redhat-undercloud ~]$




I am using following command to deploy overcloud:


openstack overcloud deploy --templates -e
/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
\
-e ~/templates/network-environment.yaml \
-e ~/templates/storage-environment.yaml \
--control-scale 1 --compute-scale 1 --control-flavor control
--compute-flavor compute \
--ntp-server 0.north-america.pool.ntp.org --neutron-network-type vxlan
--neutron-tunnel-types vxlan \
--validation-errors-fatal --validation-warnings-fatal --timeout 90
-


No errors I could find in os-collect-config or heat logs except following:

Aug 22 23:52:03 localhost os-collect-config:
/var/lib/os-collect-config/local-data not found. Skipping
Aug 22 23:52:03 localhost os-collect-config: No local metadata found
(['/var/lib/os-collect-config/local-data'])


I have looked into /var/log/heat/*, os-collect-config logs. Any other log
files that I should look into?


Thanks & Regards,
Shyam Biradar,
Email: shyambiradarsgg...@gmail.com,
Contact: +91 8600266938.
___
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] [tripleo] mismatch of user/group id between ovs (baremetal) and libvirt (container)

[Saravanan KR]

On Wed, Aug 23, 2017 at 4:28 AM, Oliver Walsh  wrote:
> Hi,
>
>>   sed -i 's/Group=qemu/Group=42427/'
>> /usr/lib/systemd/system/ovs-vswitchd.service
>
> Can't this be overridden via /etc/systemd/system/ovs-vswitchd.service?
>
Yes. I just provided the changes done on a existing deployment to make
it work. I will incorporate it to templates.

>> This change basically runs ovs with group id of kolla's qemu user
>> (42427). For the solution, my opinion is that we don't require host's
>> qemu (107) user in a containerized deployment. I am planning to ensure
>> that kolla's user id (42427) is updated to the host via the host prep
>> tasks. Let me know if there is any other aspects to be considered.
>>
>
> Might be worth considering overriding the qemu uid/gid to 107 in the
> kolla config file instead.

Definitely it will be good for upgrade to keep the same uid/gid so
that existing DPDK based VMs continue to work after upgrade.

But any other specific reasons for sticking with same qemu uid/gid in
kolla containers? Do you foresee any particular cases related to it?

Regards,
Saravanan KR

>
> Regards,
> Ollie
>
> __
> 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