[openstack-dev] [octavia] amphora fails to send request to members

[Yipei Niu]

Hi, all,

I created a lb whose vip is 10.0.1.4. When requesting the vip, i cannot
receive the responses. Hence, I console in the amphora and trace packets
handled by eth0 in the amphora-haproxy network namespace. The detailed info
is as follows.

ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy tcpdump -i eth1 -nn
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C07:25:24.225614 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq
1637781601, win 28200, options [mss 1410,sackOK,TS val 30692602 ecr
0,nop,wscale 7], length 0
07:25:24.237854 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:25.224801 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:25.228610 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
win 28200, options [mss 1410,sackOK,TS val 30692853 ecr 0,nop,wscale 7],
length 0
07:25:26.224533 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:27.230911 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:27.250858 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
win 28200, options [mss 1410,sackOK,TS val 30693359 ecr 0,nop,wscale 7],
length 0
07:25:28.228796 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:29.228697 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:29.290551 ARP, Request who-has 10.0.1.4 tell 10.0.1.2, length 28
07:25:29.290985 ARP, Reply 10.0.1.4 is-at fa:16:3e:be:5a:d5, length 28
07:25:31.251122 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:32.248737 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
07:25:33.250309 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28

14 packets captured
14 packets received by filter
0 packets dropped by kernel

As shown above, the amphora can receive the requests comes from outside but
it fails to find 10.0.1.1. As a result, amphora cannot send the request to
its load balancing member.

To further demonstrate my environment, the route table and arp cache are
listed as follows.

ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy route
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
default 10.0.1.10.0.0.0 UG0  00 eth1
10.0.1.0*   255.255.255.0   U 0  00 eth1

ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy arp
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
Address  HWtype  HWaddress   Flags Mask
Iface
10.0.1.2 ether   fa:16:3e:62:68:a8   C
 eth1
10.0.1.1 (incomplete)
eth1

What do you think? Look forward to your comments. Thank you.

Best regards,
Yipei
__
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] Building Openstack Trove Images

[Ritesh Vishwakarma]

Hi Ian,


We have installed Openstack Pike on Cent OS7 and we want to build mysql
image in order to use with Trove. I have tried out most of the references
that are available on the internet however, it’s just not working out for
me.


For now, kindly can share some detailed references and a brief overview on
how to build the image, I will go through that and get back to you if any
further assistance is required. I am looping in one of my fellow engineers
into this conversation.



Thanks for your support.



Regards,

Ritesh

On Wed, Nov 8, 2017 at 12:13 PM, Ian Wienand  wrote:

> On 11/07/2017 05:40 PM, Ritesh Vishwakarma wrote:
> > as the *dib-lint* file is there instead of the mentioned
> > *disk-image-create *and when executed just verifies the other
> > elements.
>
> Those instructions unfortunately look out of date for master
> diskimage-builder.  I will try to get a minute to parse them and
> update later.
>
> You will probably have a lot more success installing diskimage-builder
> into a virtualenv; see [1] ... then activate the virtualenv and use
> disk-image-create from there.  Likely the rest will work.
>
> If diskimage-builder is the problem, feel free to jump into
> #openstack-dib (best during .au hours to catch me) and we can help.
>
> [1] https://docs.openstack.org/diskimage-builder/latest/user_
> guide/installation.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

[openstack-dev] [vitrage] send notification when update vertex

[dong.wenjuan]

Hi dan,






I use Vitrage master branch to test 'host_down' scenario.. 


When scenario_evaluator match  the ''host_down_alarm_on_host" scenario and Do 
'mark_down' action,

Process update the vertex in entity graph and then should send the notification.

But currently, it didn't send the notification.

I trace the log but didn't find the reason.

Can you help me to have a look at? Thanks~







The vitrage-graph log and config file are in attachment.  From i post the 
'computer.host.down' event  to finish the evaluator.


Use the 'host_down' template in Vitrage repo: 
etc/vitrage/templates.sample/host_down_scenarios.yaml






BR,


dwj

vitrage.conf
Description: Binary data


vitrage_graph_for_host_down.txt
Description: Binary data
__
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] [tripleO] building overcloud image with opendaylight

[Moshe Levi]

Hi all,

We are now working on to support the OVS hardware offload with opendaylight 
deployment.
First setup we want to deploy triple with just opendaylight mechanism driver.
I have some question regarding the deployment:

1 . As I understand from the documentation the we need to build overcloud with 
odl  is that right?
2. where do I get the latest odl rpm for centos?

Thanks in advance,

Moshe
__
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] Building Openstack Trove Images

[Ian Wienand]

On 11/07/2017 05:40 PM, Ritesh Vishwakarma wrote:
> as the *dib-lint* file is there instead of the mentioned
> *disk-image-create *and when executed just verifies the other
> elements.

Those instructions unfortunately look out of date for master
diskimage-builder.  I will try to get a minute to parse them and
update later.

You will probably have a lot more success installing diskimage-builder
into a virtualenv; see [1] ... then activate the virtualenv and use
disk-image-create from there.  Likely the rest will work.

If diskimage-builder is the problem, feel free to jump into
#openstack-dib (best during .au hours to catch me) and we can help.

[1] 
https://docs.openstack.org/diskimage-builder/latest/user_guide/installation.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] Building Openstack Trove Images

[Ritesh Vishwakarma]

++Looping my fellow engineer.

On Wed, Nov 8, 2017 at 2:34 AM, Amrith Kumar  wrote:

> Ritesh,
>
> Your answers don't help me understand the problems you are having. So
> let's try this instead.
>
> 1. What (exact) version of OpenStack are you using? Is it from upstream or
> a vendor, if it is the latter, which vendor?
> 2. What database (exact version) are you trying to create an image for?
> 3. What operating system (exact version) are you attempting to perform
> this on?
> 4. What command(s) are you executing?
> 5. What exact error(s) are you receiving?
>
> For #4 and #5 it would be ideal if you just cut/pasted a terminal session
> into an etherpad or gist or pastebuffer or some such thing and shared that
> link via email. If you have passwords and other sensitive stuff, make sure
> you redact it.
>
> Thanks.
>
> -amrith
>
>
>
> On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>>
>> Many Thanks for your response. Hope you are doing well!
>>
>>
>> The confusing part here is that the OpenStack tutorial page itself not
>> seems to be updated https://docs.openstack.org/tro
>> ve/latest/admin/building_guest_images.html#build-guest-images
>>
>> as the *dib-lint* file is there instead of the mentioned *disk-image-create
>> *and when executed just verifies the other elements.
>>
>> I have also tried using https://github.com/denismakogo
>> n/trove-guest-image-elements but the error on which I got stuck is
>> “deltarpm not installed” (deltarpm is installed on the host machine).
>> Though yesterday, I came across the https://github.com/openstack/t
>> rove-integration which I am going to try out today, kindly let me know
>> if it is the right one or please share any relevant reference on which we
>> can work.
>>
>>
>>
>> Regards,
>>
>> Ritesh
>>
>> On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar 
>> wrote:
>>
>>> Ha, it isn't often that I get called out by name in a mailing list
>>> thread.
>>>
>>> What are the issues that you are facing? Currently there are complete
>>> notes about how to build guest images but the issues you may be facing may
>>> not relate to the images you are building.
>>>
>>> So please provide some more details so I can give you a more accurate
>>> reply.
>>> ​
>>> ​Thanks,​
>>>
>>>
>>> -amrith
>>>
>>>
>>> On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 Hi Team,

 We have installed Openstack Pike in our campus but despite of numerous
 attempts we are just unable to build trove images that we can use to launch
 database instances.We also came across a mail thread where Mr. Amrith
 updates that some review & update of the OpenStack Trove documents was
 going on, kindly provide us some reference document or link which we can
 follow.

 https://lists.gt.net/openstack/dev/58182

 We will be eagerly waiting for your response.



 Thanks  & Regards,
 Ritesh Vishwakarma

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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] Moving the virt_mkfs flags to privsep

[Michael Still]

That does work for me, except it means I'll still need to port it to
privsep to hit my goal of no rootwrap in Queens. I can live with that.

Michael

On Wed, Nov 8, 2017 at 4:54 PM, Matt Riedemann  wrote:

> On 11/8/2017 12:24 PM, Michael Still wrote:
>
>> Hi,
>>
>> a really really long time ago (think 2011), we added support in Nova for
>> configuring the mkfs commands that are run for new ephemeral disks using
>> the virt_mkfs command. The current implementation is in
>> nova/virt/disk/api.py for your reading pleasure.
>>
>> I'm battling a little with how to move this code to privsep, because I
>> have resisted providing any method which just takes a command line and runs
>> it with escalated permissions, as I feel this defeats the purpose of
>> privsep.
>>
>> I could just pickup all the command line parsing code and move it into
>> privsep, but I am left wondering if anyone actually uses this
>> functionality, or if we should just deprecate it all?
>>
>> I'd appreciate your thoughts.
>>
>> Michael
>>
>>
>> 
>> __
>> 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
>>
>>
> Let's deprecate it, put a warning in the logs if it's used in Queens,
> deprecation release note and then remove it in Rocky.
>
> Does that work for you?
>
> --
>
> 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

Re: [openstack-dev] [neutron][networking-odl]

[Takashi Yamamoto]

On Wed, Nov 8, 2017 at 3:15 PM, Bhatia, Manjeet S
 wrote:
>
>
>> -Original Message-
>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>> Sent: Tuesday, November 7, 2017 10:13 PM
>> To: Bhatia, Manjeet S 
>> Cc: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [neutron][networking-odl]
>>
>> hi,
>>
>> On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
>>  wrote:
>> > Hello Neutrinos,
>> >
>> >
>> >
>> > I’ve been trying service profile flavors for L3 in neutron to register
>> > the driver,
>> >
>> > the method I’ve been using is below
>> >
>> >
>> >
>> > I have this added to neutron.conf
>> >
>> > [service_providers]
>> >
>> > service_provider =
>> > L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:def
>> > ault
>>
>> where do you have this driver?
>
> In networking-odl local repo as WIP.

a similar procedure [1] worked for me with midonet POC code. [2]
so i suspect there's something wrong in your local code.

[1] 
https://review.openstack.org/#/c/483174/2/midonet/neutron/services/l3/service_providers/l3_midonet.py@38
[2] https://review.openstack.org/#/c/483174/

>
>>
>> >
>> >
>> >
>> > and then tried creating flavor profile
>> >
>> > [a]. openstack network flavor profile create --driver
>> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider
>> >
>> >
>> >
>> > It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
>> > req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
>> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
>> >
>> >
>> >
>> > Here is trace from log http://paste.openstack.org/show/625178/ seems
>> > like resource not found,
>> >
>> >
>> >
>> > But I also noticed in [1]. self.config is {}
>> >
>> >
>> >
>> >
>> >
>> > [1].
>> > https://github.com/openstack/neutron/blob/master/neutron/db/servicetyp
>> > e_db.py#L55
>> >
>> >
>> >
>> >
>> >
>> > Any pointers what’s being done wrong is it the enabling of service
>> > profiles flavor or something else ?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Thanks and regards !
>> >
>> > Manjeet
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-odl]

[Bhatia, Manjeet S]

> -Original Message-
> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
> Sent: Tuesday, November 7, 2017 10:13 PM
> To: Bhatia, Manjeet S 
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][networking-odl]
> 
> hi,
> 
> On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
>  wrote:
> > Hello Neutrinos,
> >
> >
> >
> > I’ve been trying service profile flavors for L3 in neutron to register
> > the driver,
> >
> > the method I’ve been using is below
> >
> >
> >
> > I have this added to neutron.conf
> >
> > [service_providers]
> >
> > service_provider =
> > L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:def
> > ault
> 
> where do you have this driver?

In networking-odl local repo as WIP. 

> 
> >
> >
> >
> > and then tried creating flavor profile
> >
> > [a]. openstack network flavor profile create --driver
> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider
> >
> >
> >
> > It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
> > req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
> >
> >
> >
> > Here is trace from log http://paste.openstack.org/show/625178/ seems
> > like resource not found,
> >
> >
> >
> > But I also noticed in [1]. self.config is {}
> >
> >
> >
> >
> >
> > [1].
> > https://github.com/openstack/neutron/blob/master/neutron/db/servicetyp
> > e_db.py#L55
> >
> >
> >
> >
> >
> > Any pointers what’s being done wrong is it the enabling of service
> > profiles flavor or something else ?
> >
> >
> >
> >
> >
> >
> >
> > Thanks and regards !
> >
> > Manjeet
> >
> >
> >
> >
> >
> >
> >
> >
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-odl]

[Takashi Yamamoto]

hi,

On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
 wrote:
> Hello Neutrinos,
>
>
>
> I’ve been trying service profile flavors for L3 in neutron to register the
> driver,
>
> the method I’ve been using is below
>
>
>
> I have this added to neutron.conf
>
> [service_providers]
>
> service_provider =
> L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:default

where do you have this driver?

>
>
>
> and then tried creating flavor profile
>
> [a]. openstack network flavor profile create --driver
> networking_odl.l3.l3_flavor.ODLL3ServiceProvider
>
>
>
> It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
> req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
> networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
>
>
>
> Here is trace from log http://paste.openstack.org/show/625178/ seems like
> resource not found,
>
>
>
> But I also noticed in [1]. self.config is {}
>
>
>
>
>
> [1].
> https://github.com/openstack/neutron/blob/master/neutron/db/servicetype_db.py#L55
>
>
>
>
>
> Any pointers what’s being done wrong is it the enabling of service profiles
> flavor or something else ?
>
>
>
>
>
>
>
> Thanks and regards !
>
> Manjeet
>
>
>
>
>
>
>
>

__
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][neutron] How do you use the instance IP filter?

[Matt Riedemann]

On 10/27/2017 1:23 PM, Matt Riedemann wrote:
Nova has had this long-standing known performance issue if you're 
filtering a large number of instances by IP. The instance IPs are stored 
in a JSON blob in the database so we don't do filtering in SQL. We pull 
the instances out of the database, deserialize the JSON and then apply a 
regex filter match in the nova-api python code.


At the Queens PTG we talked about possible ways to fix this and came up 
with this nova spec:


https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/improve-filter-instances-by-ip-performance.html 



The idea is to have nova get ports from neutron and apply the IP filter 
in neutron to whittle down the ports, then from that list of ports get 
the instances to pull out of the nova database.


One issue that has come up with this is neutron does not currently 
support regex filters when listing ports. There is an RFE for adding that:


https://bugs.launchpad.net/neutron/+bug/1718605

The proposed neutron implementation is to just do SQL LIKE substring 
matching in the database.


However, one issue that has come up is that the compute API accepts a 
python regex filter and uses re.match():


https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469

At least one good thing about that is match() only matches from the 
beginning of the string unlike search().


So for example I can filter on "192.16.*[1-5]$" if I wanted to, but 
that's not going to work with just a LIKE substring filter in SQL.


The question is, does anyone actually do more than basic substring 
matching with the IP filter today? Because if we started using neutron, 
that behavior would be broken. We've never actually documented the match 
restrictions on the IP filter, but that's not a good reason to break it.


One option is to make this configurable such that deployments which rely 
on the complicated pattern matching can just use the existing nova code 
despite performance issues. However, that's not interoperable, I hate 
config-driven API behavior, and it would mean maintaining two code paths 
in nova, which is also terrible.


I was trying to think of a way to determine if the IP filter passed to 
nova is basic or a complicated pattern match and let us decide that way, 
but I'm not sure if there are good ways to detect that - maybe by simply 
looking for special characters like (, ), - and $? But then there is [] 
and we have an IPv6 filter, so that gets messy too...


For now I'd just like to know if people rely on the regex match or not. 
Other ideas on how to handle this are appreciated.




To paraphrase the nova queens roadmap and checkpoint session at the 
summit [1] we agreed to just do LIKE in-SQL regex filtering in Neutron. 
The operators in the room (and from this thread in the ML) have said 
they are doing exact IP filter matches, not regex. The LIKE regex 
filtering in SQL still gives some flexibility with regex, but not the 
crazy python re thing nova allows today (which is potentially an attack 
vector).


So we'll move forward with those changes.

[1] https://etherpad.openstack.org/p/SYD-forum-nova-queens-update

--

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

Re: [openstack-dev] [Nova] Moving the virt_mkfs flags to privsep

[Matt Riedemann]

On 11/8/2017 12:24 PM, Michael Still wrote:

Hi,

a really really long time ago (think 2011), we added support in Nova for 
configuring the mkfs commands that are run for new ephemeral disks using 
the virt_mkfs command. The current implementation is in 
nova/virt/disk/api.py for your reading pleasure.


I'm battling a little with how to move this code to privsep, because I 
have resisted providing any method which just takes a command line and 
runs it with escalated permissions, as I feel this defeats the purpose 
of privsep.


I could just pickup all the command line parsing code and move it into 
privsep, but I am left wondering if anyone actually uses this 
functionality, or if we should just deprecate it all?


I'd appreciate your thoughts.

Michael


__
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



Let's deprecate it, put a warning in the logs if it's used in Queens, 
deprecation release note and then remove it in Rocky.


Does that work for you?

--

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

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Dan Sneddon]

On Mon, Nov 6, 2017 at 6:32 AM, Honza Pokorny  wrote:

> Hello people,
>
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.
>
> Thanks
>
> Honza Pokorny
>
> __
> 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
>

+1, glad to hear it.

-- 
Dan Sneddon |  Senior Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Steven Hardy]

On Mon, Nov 6, 2017 at 2:32 PM, Honza Pokorny  wrote:
> Hello people,
>
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.

+1!

__
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] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

[Steven Hardy]

Hi all,

Today I had a productive hallway discussion with jtomasek and
stevebaker re $subject, so I wanted to elaborate here for the benefit
of those folks not present.  Hopefully we can get feedback on the
ideas and see if it makes sense to continue and work on some patches:

The problem under discussion is how do we run pre-deployment workflows
(such as those integrated recently to calculate derived parameters,
and in future perhaps also those which download container images etc),
and in particular how do we make these discoverable via the UI
(including any input parameters).

The idea we came up with has two parts:

1. Add a new optional section to roles_data for services that require
pre-deploy workflows

E.g something like this:

 pre_deploy_workflows:
- derive_params:
  workflow_name:
tripleo.derive_params_formulas.v1.dpdk_derive_params
  inputs:
  ...

This would allow us to associate a specific mistral workflow with a
given service template, and also work around the fact that currently
mistral inputs don't have any schema (only key/value input) as we
could encode the required type and any constraints in the inputs block
(clearly this could be removed in future should typed parameters
become available in mistral).

2. Add a new workflow that calculates the enabled services and returns
all pre_deploy_workflows

This would take all enabled environments, then use heat to validate
the configuration and return the merged resource registry (which will
require https://review.openstack.org/#/c/509760/), then we would
iterate over all enabled services in the registry and extract a given
roles_data key (e.g pre_deploy_workflows)

The result of the workflow would be a list of all pre_deploy_workflows
for all enabled services, which the UI could then use to run the
workflows as part of the pre-deploy process.

If this makes sense I can go ahead and push some patches so we can
iterate on the implementation?

Thanks,

Steve

__
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] Upstream LTS Releases

[Erik McCormick]

On Nov 8, 2017 1:52 PM, "James E. Blair"  wrote:

Erik McCormick  writes:

> On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair 
wrote:
>> Erik McCormick  writes:
>>
>>> The concept, in general, is to create a new set of cores from these
>>> groups, and use 3rd party CI to validate patches. There are lots of
>>> details to be worked out yet, but our amazing UC (User Committee) will
>>> be begin working out the details.
>>
>> I regret that due to a conflict I was unable to attend this session.
>> Can you elaborate on why third-party CI would be necessary for this,
>> considering that upstream CI already exists on all active branches?
>
> Lack of infra resources, people are already maintaining their own
> testing for old releases, and distribution of work across
> organizations I think were the chief reasons. Someone else feel free
> to chime in and expand on it.

Which resources are lacking?  I wasn't made aware of a shortage of
upstream CI resources affecting stable branch work, but if there is, I'm
sure we can address it -- this is a very important effort.




It's not a matter of things lacking for today's release cadence and
deprecation policy. That is working fine.  The problems would come if you
had to,  say,  continue to run it for Mitaka until Queens is released.

The upstream CI system is also a collaboratively maintained system with
folks from many organizations participating in it.  Indeed we're now
distributing its maintenance and operation into projects themselves.
It seems like an ideal place for folks from different organizations to
collaborate.


Monty, as well as the Stable Branch cores, were in the room, so perhaps
they can elaborate on this for us.  I'm no expert on what can and cannot be
done.

-Jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Nominate akrivoka for tripleo-validations core

[Jiri Tomasek]

+1, great work Ana!

út 7. 11. 2017 v 1:33 odesílatel Honza Pokorny  napsal:

> Hello people,
>
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.
>
> Thanks
>
> Honza Pokorny
>
> __
> 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] Upstream LTS Releases

[James E. Blair]

Erik McCormick  writes:

> On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair  wrote:
>> Erik McCormick  writes:
>>
>>> The concept, in general, is to create a new set of cores from these
>>> groups, and use 3rd party CI to validate patches. There are lots of
>>> details to be worked out yet, but our amazing UC (User Committee) will
>>> be begin working out the details.
>>
>> I regret that due to a conflict I was unable to attend this session.
>> Can you elaborate on why third-party CI would be necessary for this,
>> considering that upstream CI already exists on all active branches?
>
> Lack of infra resources, people are already maintaining their own
> testing for old releases, and distribution of work across
> organizations I think were the chief reasons. Someone else feel free
> to chime in and expand on it.

Which resources are lacking?  I wasn't made aware of a shortage of
upstream CI resources affecting stable branch work, but if there is, I'm
sure we can address it -- this is a very important effort.

The upstream CI system is also a collaboratively maintained system with
folks from many organizations participating in it.  Indeed we're now
distributing its maintenance and operation into projects themselves.
It seems like an ideal place for folks from different organizations to
collaborate.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[James Slagle]

On Tue, Nov 7, 2017 at 4:59 PM, Emilien Macchi  wrote:
> Yes. Thanks for reformulate with better words.
> Just to be clear, I want to transform the scenarios into single-node
> jobs that deploy the SAME services (using composable services) from
> the undercloud, using the new ansible installer. I also want to keep
> running Tempest.
> And of course, like we said, keep one multinode job to test overcloud
> workflow, and OVB with some adjustments.
>
> Is it good?

+1


-- 
-- James Slagle
--

__
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] [Nova] Moving the virt_mkfs flags to privsep

[Michael Still]

Hi,

a really really long time ago (think 2011), we added support in Nova for
configuring the mkfs commands that are run for new ephemeral disks using
the virt_mkfs command. The current implementation is in
nova/virt/disk/api.py for your reading pleasure.

I'm battling a little with how to move this code to privsep, because I have
resisted providing any method which just takes a command line and runs it
with escalated permissions, as I feel this defeats the purpose of privsep.

I could just pickup all the command line parsing code and move it into
privsep, but I am left wondering if anyone actually uses this
functionality, or if we should just deprecate it all?

I'd appreciate your thoughts.

Michael
__
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] Upstream LTS Releases

[Thierry Carrez]

Erik McCormick wrote:
> This morning at the Sydney Summit we had a very well attended and very
> productive session about how to go about keeping a selection of past
> releases available and maintained for a longer period of time (LTS).
> 
> There was agreement in the room that this could be accomplished by
> moving the responsibility for those releases from the Stable Branch
> team down to those who are already creating and testing patches for
> old releases: The distros, deployers, and operators.
> 
> The concept, in general, is to create a new set of cores from these
> groups, and use 3rd party CI to validate patches. There are lots of
> details to be worked out yet, but our amazing UC (User Committee) will
> be begin working out the details.

I took the action of summarizing the discussion in more detail, will do
as soon as my brain is not as mushy, which might take a couple of weeks :)

Note that it's not really about devs vs. ops, with devs abdicating all
responsibility on stable branches : it's about allowing collaboration on
patches beyond EOL (which is what we are able to support with "live"
stable branches on evolving OS/PyPI substrate) and enable whoever steps
up to maintain longer-lived branches to come up with a set of tests that
actually match their needs (tests that would be less likely to bitrot
due to changing OS/PyPI substrate).

A number of people from all backgrounds volunteered to flesh out a more
detailed proposal. Watch that space!

-- 
Thierry Carrez (ttx)

__
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] Upstream LTS Releases

[Erik McCormick]

On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair  wrote:
> Erik McCormick  writes:
>
>> The concept, in general, is to create a new set of cores from these
>> groups, and use 3rd party CI to validate patches. There are lots of
>> details to be worked out yet, but our amazing UC (User Committee) will
>> be begin working out the details.
>
> I regret that due to a conflict I was unable to attend this session.
> Can you elaborate on why third-party CI would be necessary for this,
> considering that upstream CI already exists on all active branches?
>
> Thanks,
>
> Jim

Lack of infra resources, people are already maintaining their own
testing for old releases, and distribution of work across
organizations I think were the chief reasons. Someone else feel free
to chime in and expand on it.

-Erik

__
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] Upstream LTS Releases

[James E. Blair]

Erik McCormick  writes:

> The concept, in general, is to create a new set of cores from these
> groups, and use 3rd party CI to validate patches. There are lots of
> details to be worked out yet, but our amazing UC (User Committee) will
> be begin working out the details.

I regret that due to a conflict I was unable to attend this session.
Can you elaborate on why third-party CI would be necessary for this,
considering that upstream CI already exists on all active branches?

Thanks,

Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

[Adam Spiers]

Michał Jastrzębski  wrote:

Hello my dearest of communities,

During deployment tools session on PTG we discussed need for deep
health checking and metering of running services. It's very relevant
in context of containers (especially k8s) and HA. Things like
watchdog, heartbeats or exposing relative metrics (I don't want to get
into design here, suffice to say it's non-trivial problem to solve).

We would like to start a "task force", few volunteers from both
deployment tool side (ops, ha) and project dev teams. We would like to
design together a proper health check mechanism for one of projects to
create best practices and design, that later could be implemented in
all other services.

We would to ask for volunteer project team to join us and spearhead this effort.


Sorry for the late reply - I only just found this thread.  But I would
certainly like to be involved too :-)

__
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] Upstream LTS Releases

[Erik McCormick]

Hello Ops folks,

This morning at the Sydney Summit we had a very well attended and very
productive session about how to go about keeping a selection of past
releases available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo]

[Emilien Macchi]

On Wed, Nov 8, 2017 at 9:54 AM, Wesley Hayutin  wrote:
[...]
> There are already several upgrade jobs defined in the experimental queue
> that can be triggered with "check rdo experimental"
> Let's iterate on those, and then make them full 3rd party check jobs.
> We talked about allowing rdo sf to -2 reviews upstream as well which would
> be handy.

LGTM. Thanks for the clarification.
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo]

[Wesley Hayutin]

On Tue, Nov 7, 2017 at 5:47 PM, Emilien Macchi  wrote:

> On Wed, Nov 8, 2017 at 9:29 AM, Wesley Hayutin 
> wrote:
> > Greetings,
> >
> > I'd like to propose we remove the upgrade jobs that are consistently
> failing
> > from the upstream infrastructure and instead focus our efforts in RDO
> > Software Factory.
> >
> > The jobs listed in https://review.openstack.org/#/c/518405/ are
> consistently
> > failing after being reviewed by myself and Mathieu.  I am leaving
> > legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's passing
> with
> > an overall rate of 87%.
> >
> > It doesn't make any sense to continue to tax upstream resources on
> failing
> > jobs, lets get the jobs running correctly and consistently in rdo
> software
> > factory before moving these back to our mainline CI.
> >
> > Please let me know what you think of the proposal.
>
> +1 to remove them if we have the scenario upgrades (with parity from
> what we had upstream) in RDO CI.
> We'll need to make the job experimental in RDO CI, so we can only run
> them at demand until they actually work. Can we do that as well?
>
> Thanks,
>

There are already several upgrade jobs defined in the experimental queue
that can be triggered with "check rdo experimental"
Let's iterate on those, and then make them full 3rd party check jobs.
We talked about allowing rdo sf to -2 reviews upstream as well which would
be handy.

Thanks guys


> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo]

[Emilien Macchi]

On Wed, Nov 8, 2017 at 9:29 AM, Wesley Hayutin  wrote:
> Greetings,
>
> I'd like to propose we remove the upgrade jobs that are consistently failing
> from the upstream infrastructure and instead focus our efforts in RDO
> Software Factory.
>
> The jobs listed in https://review.openstack.org/#/c/518405/ are consistently
> failing after being reviewed by myself and Mathieu.  I am leaving
> legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's passing with
> an overall rate of 87%.
>
> It doesn't make any sense to continue to tax upstream resources on failing
> jobs, lets get the jobs running correctly and consistently in rdo software
> factory before moving these back to our mainline CI.
>
> Please let me know what you think of the proposal.

+1 to remove them if we have the scenario upgrades (with parity from
what we had upstream) in RDO CI.
We'll need to make the job experimental in RDO CI, so we can only run
them at demand until they actually work. Can we do that as well?

Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo]

[Jason E. Rist]

On 11/07/2017 03:29 PM, Wesley Hayutin wrote:
> Greetings,
>
> I'd like to propose we remove the upgrade jobs that are consistently
> failing from the upstream infrastructure and instead focus our efforts in
> RDO Software Factory.
>
> The jobs listed in https://review.openstack.org/#/c/518405/ are
> consistently failing after being reviewed by myself and Mathieu.  I am
> leaving legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's
> passing with an overall rate of 87%.
>
> It doesn't make any sense to continue to tax upstream resources on failing
> jobs, lets get the jobs running correctly and consistently in rdo software
> factory before moving these back to our mainline CI.
>
> Please let me know what you think of the proposal.
> Thanks
>
> The upgrade job configuration for upgrades can be found in [1]
> [1]
> https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/jobs/tripleo-upstream.yml
>
>
>
> __
> 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
>
Seconded.

__
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] [tripleo]

[Wesley Hayutin]

Greetings,

I'd like to propose we remove the upgrade jobs that are consistently
failing from the upstream infrastructure and instead focus our efforts in
RDO Software Factory.

The jobs listed in https://review.openstack.org/#/c/518405/ are
consistently failing after being reviewed by myself and Mathieu.  I am
leaving legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's
passing with an overall rate of 87%.

It doesn't make any sense to continue to tax upstream resources on failing
jobs, lets get the jobs running correctly and consistently in rdo software
factory before moving these back to our mainline CI.

Please let me know what you think of the proposal.
Thanks

The upgrade job configuration for upgrades can be found in [1]
[1]
https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/jobs/tripleo-upstream.yml
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Emilien Macchi]

On Wed, Nov 8, 2017 at 3:30 AM, James Slagle  wrote:
> On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi  wrote:
>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince  wrote:
>> [...]
>>
>>>  -CI resources: better use of CI resources. At the PTG we received
>>> feedback from the OpenStack infrastructure team that our upstream CI
>>> resource usage is quite high at times (even as high as 50% of the
>>> total). Because of the shared framework and single node capabilities we
>>> can re-architecture much of our upstream CI matrix around single node.
>>> We no longer require multinode jobs to be able to test many of the
>>> services in tripleo-heat-templates... we can just use a single cloud VM
>>> instead. We'll still want multinode undercloud -> overcloud jobs for
>>> testing things like HA and baremetal provisioning. But we can cover a
>>> large set of the services (in particular many of the new scenario jobs
>>> we added in Pike) with single node CI test runs in much less time.
>>
>> After the last (terrible) weeks in CI, it's pretty clear we need to
>> find a solution to reduce and optimize our testing.
>> I'm now really convinced by switching our current scenarios jobs to
>> NOT deploy the overcloud, and just an undercloud with composable
>> services & run tempest.
>
> +1 if you mean just the scenarios.

Yes, just scenarios.

> I think we need to keep at least 1 multinode job voting that deploys
> the overcloud, probably containers-multinode.

Yes, exactly, and also work on optimizing OVB jobs (maybe just keep
one or 2 jobs, instead 3).

>> Benefits:
>> - deploy 1 node instead of 2 nodes, so we save nodepool resources
>> - faster (no overcloud)
>> - reduce gate queue time, faster development process, faster CI
>>
>> Challenges:
>> - keep overcloud testing, with OVB
>
> This is why I'm not sure what you're proposing. Do you mean switch all
> multinode jobs to be just an undercloud, or just the scenarios?

Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be
tested with multinode though but well).

>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic
>> containerized services on overcloud.
>>
>> I really want to get consensus on these points, please raise your
>> voice now before we engage some work on that front.
>
> I'm fine to optimize the scenarios to be undercloud driven, but feel
> we still need a multinode job that deploys the overcloud in the gate.
> Otherwise, we'll have nothing that deploys an overcloud in the gate,
> which is a step in the wrong direction imo. Primarily, b/c of the loss
> of coverage around mistral and all of our workflows. Perhaps down the
> road we could find ways to optimize that by using an ephemeral Mistral
> (similar to the ephemeral Heat container), and then use a single node,
> but we're not there yet.
>
> On the other hand, if the goal is just to test less upstream so that
> we can more quickly merge code, then *not* deploying an overcloud in
> the gate at all seems to fit that goal. Is that what you're after?

Yes. Thanks for reformulate with better words.
Just to be clear, I want to transform the scenarios into single-node
jobs that deploy the SAME services (using composable services) from
the undercloud, using the new ansible installer. I also want to keep
running Tempest.
And of course, like we said, keep one multinode job to test overcloud
workflow, and OVB with some adjustments.

Is it good?

Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

Ritesh,

Your answers don't help me understand the problems you are having. So let's
try this instead.

1. What (exact) version of OpenStack are you using? Is it from upstream or
a vendor, if it is the latter, which vendor?
2. What database (exact version) are you trying to create an image for?
3. What operating system (exact version) are you attempting to perform this
on?
4. What command(s) are you executing?
5. What exact error(s) are you receiving?

For #4 and #5 it would be ideal if you just cut/pasted a terminal session
into an etherpad or gist or pastebuffer or some such thing and shared that
link via email. If you have passwords and other sensitive stuff, make sure
you redact it.

Thanks.

-amrith


On Tue, Nov 7, 2017 at 5:40 PM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amrith,
>
>
> Many Thanks for your response. Hope you are doing well!
>
>
> The confusing part here is that the OpenStack tutorial page itself not
> seems to be updated https://docs.openstack.org/
> trove/latest/admin/building_guest_images.html#build-guest-images
>
> as the *dib-lint* file is there instead of the mentioned *disk-image-create
> *and when executed just verifies the other elements.
>
> I have also tried using https://github.com/denismakogon/trove-guest-
> image-elements but the error on which I got stuck is “deltarpm not
> installed” (deltarpm is installed on the host machine). Though yesterday, I
> came across the https://github.com/openstack/trove-integration which I am
> going to try out today, kindly let me know if it is the right one or please
> share any relevant reference on which we can work.
>
>
>
> Regards,
>
> Ritesh
>
> On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar 
> wrote:
>
>> Ha, it isn't often that I get called out by name in a mailing list thread.
>>
>> What are the issues that you are facing? Currently there are complete
>> notes about how to build guest images but the issues you may be facing may
>> not relate to the images you are building.
>>
>> So please provide some more details so I can give you a more accurate
>> reply.
>> ​
>> ​Thanks,​
>>
>>
>> -amrith
>>
>>
>> On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Team,
>>>
>>> We have installed Openstack Pike in our campus but despite of numerous
>>> attempts we are just unable to build trove images that we can use to launch
>>> database instances.We also came across a mail thread where Mr. Amrith
>>> updates that some review & update of the OpenStack Trove documents was
>>> going on, kindly provide us some reference document or link which we can
>>> follow.
>>>
>>> https://lists.gt.net/openstack/dev/58182
>>>
>>> We will be eagerly waiting for your response.
>>>
>>>
>>>
>>> Thanks  & Regards,
>>> Ritesh Vishwakarma
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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] [charms] nominating admcleod for core openstack charmer

[Ryan Beisner]

Hi OpenStack Charmers,

I'd like to nominate Andrew McLeod (admcleod) to be promoted as a core
reviewer for the OpenStack Charms project.  I trust Andrew's judgement in
code review and collaboration with other core reviewers.

Please take this to the next IRC meeting for discussion and determination.
Thank you.

Cheers,

Ryan
__
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] [QA] No team meeting tomorrow

[Andrea Frittoli]

Hello team,

since a few of us will either still be in Sydney or travelling back, I'm
cancelling the meeting tomorrow Nov 9 at 17UTC.

Cheers,

Andrea Frittoli (andreaf)
__
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] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. CI migration to Zuul v3: take legacy jobs in tree: 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking
1.1. repair stable branches by backporting the jobs to them
1.2. Fix missing 'Zuul gate' job: https://review.openstack.org/#/c/517719/
2. Move the "ironic" CLI to "latest" version: 
https://review.openstack.org/515064
3. Rolling upgrades dev docs https://review.openstack.org/#/c/419439/
4. BIOS interface spec: https://review.openstack.org/#/c/496481/

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/207337 - Out-of-band Boot from UEFI iSCSI volume 
for HPE Proliant server
irmc:
SPEC to add a new hardware type for another FUJITSU server: PRIMEQUEST MMB:
https://review.openstack.org/#/c/515717/

oneview:
Add validations for OneView ML2 driver -  
https://review.openstack.org/#/c/508946/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
folks might consider trying the test patch to experiment manually with this 
https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 30 Oct 2017 and 06 Nov 2017)
  - Ironic: 236 bugs (-15) + 248 wishlist items (-4). 13 new (-3), 166 in 
progress (-31), 0 critical, 30 high (-2) and 35 incomplete
  - Inspector: 16 bugs + 31 wishlist items. 2 new, 16 in progress, 0 critical, 
4 high and 3 incomplete
  - Nova bugs with Ironic tag: 12. 0 new, 0 critical, 1 high
- HIGH bugs with patches to review:
  - Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
  - prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
  - If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- Zuul v3 jobs in-tree migration tracking 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking
- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- local boot with partition images: TODO 
https://bugs.launchpad.net/ironic/+bug/1531149
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1671145
- status as of 06 Nov 2017:
- patches on review:
- switch the "ironic" CLI as well: https://review.openstack.org/515064 
needs review
- TODO:
- easier accept to versions in ironicclient
- establish foundation for using version negotiation in nova

External project a

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[James Slagle]

On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi  wrote:
> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince  wrote:
> [...]
>
>>  -CI resources: better use of CI resources. At the PTG we received
>> feedback from the OpenStack infrastructure team that our upstream CI
>> resource usage is quite high at times (even as high as 50% of the
>> total). Because of the shared framework and single node capabilities we
>> can re-architecture much of our upstream CI matrix around single node.
>> We no longer require multinode jobs to be able to test many of the
>> services in tripleo-heat-templates... we can just use a single cloud VM
>> instead. We'll still want multinode undercloud -> overcloud jobs for
>> testing things like HA and baremetal provisioning. But we can cover a
>> large set of the services (in particular many of the new scenario jobs
>> we added in Pike) with single node CI test runs in much less time.
>
> After the last (terrible) weeks in CI, it's pretty clear we need to
> find a solution to reduce and optimize our testing.
> I'm now really convinced by switching our current scenarios jobs to
> NOT deploy the overcloud, and just an undercloud with composable
> services & run tempest.

+1 if you mean just the scenarios.

I think we need to keep at least 1 multinode job voting that deploys
the overcloud, probably containers-multinode.

> Benefits:
> - deploy 1 node instead of 2 nodes, so we save nodepool resources
> - faster (no overcloud)
> - reduce gate queue time, faster development process, faster CI
>
> Challenges:
> - keep overcloud testing, with OVB

This is why I'm not sure what you're proposing. Do you mean switch all
multinode jobs to be just an undercloud, or just the scenarios?

> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic
> containerized services on overcloud.
>
> I really want to get consensus on these points, please raise your
> voice now before we engage some work on that front.

I'm fine to optimize the scenarios to be undercloud driven, but feel
we still need a multinode job that deploys the overcloud in the gate.
Otherwise, we'll have nothing that deploys an overcloud in the gate,
which is a step in the wrong direction imo. Primarily, b/c of the loss
of coverage around mistral and all of our workflows. Perhaps down the
road we could find ways to optimize that by using an ephemeral Mistral
(similar to the ephemeral Heat container), and then use a single node,
but we're not there yet.

On the other hand, if the goal is just to test less upstream so that
we can more quickly merge code, then *not* deploying an overcloud in
the gate at all seems to fit that goal. Is that what you're after?

-- 
-- James Slagle
--

__
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] [Octavia] networking issues

[Volodymyr Litovka]

Dear colleagues,

while trying to setup Octavia, I faced the problem of connecting amphora 
agent to VIP network.


*Environment:
*Octavia 1.0.1 (installed by using "pip install")
Openstack Pike:
- Nova 16.0.1
- Neutron 11.0.1
- Keystone 12.0.0

*Topology of testbed:*

    +
    |
    |    ++
    +   ++ n1 |
    |    +-+    |    ++
    ++ Amphora ++
    |    +-+    |    ++
  m | l ++ n2 |
  g | b |    ++    + e
  m | t |  | x
  t |   |    ++    | t
    | s ++ vR ++ e
    | u |    ++    | r
   ++ b |  | n
   | Controller | n |  | a
   ++ e |  + l
  t |
    +

*Summary:*

$ openstack loadbalancer create --name nlb2 --vip-subnet-id lbt-subnet
$ openstack loadbalancer list
+--+--+--+-+-+--+
| id   | name | 
project_id   | vip_address | provisioning_status | 
provider |

+--+--+--+-+-+--+
| 93facca0-d39a-44e0-96b6-28efc1388c2d | nlb2 | 
d8051a3ff3ad4c4bb380f828992b8178 | 1.1.1.16    | ACTIVE  | 
octavia  |

+--+--+--+-+-+--+
$ openstack server list --all
+--+--++-+-++
| ID   | 
Name | Status | 
Networks    | Image   | Flavor |

+--+--++-+-++
| 98ae591b-0270-4625-95eb-a557c1452eef | 
amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab | ACTIVE | 
lb-mgmt-net=172.16.252.28; lbt-net=1.1.1.11 | amphora | |
| cc79ca78-b036-4d55-a4bd-5b3803ed2f9b | 
lb-n1    | ACTIVE | 
lbt-net=1.1.1.18    | | B-cup |
| 6c43ccca-c808-44cf-974d-acdbdb4b26db | 
lb-n2    | ACTIVE | 
lbt-net=1.1.1.19    | | B-cup |

+--+--++-+-++

This output shows that amphora agent is active with two interfaces, 
connected to management and project's networks (lb-mgmt-net and lbt-net 
respectively). BUT in fact there is no interface to lbt-net on the 
agent's VM:


*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$* ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

[ ... ]
2: eth0:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000

    link/ether d0:1c:a0:58:e0:02 brd ff:ff:ff:ff:ff:ff
    inet 172.16.252.28/22 brd 172.16.255.255 scope global eth0
*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$* ls /sys/class/net/
_eth0_ _lo_
*ubuntu@amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab:~$*

The issue is that eth1 exists during start of agent's VM and then it 
magically disappears (snipped from syslog, note timing):


Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPREQUEST of 1.1.1.11 on eth1 to 255.255.255.255 port 
67 (xid=0x1c65db9b)
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPOFFER of 1.1.1.11 from 1.1.1.10
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: DHCPACK of 1.1.1.11 from 1.1.1.10
Nov  7 12:00:31 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1051]: bound to 1.1.1.11 -- renewal in 38793 seconds.

[ ... ]
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1116]: receive_packet failed on eth1: Network is down
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab systemd[1]: 
Stopping ifup for eth1...
Nov  7 12:00:44 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1715]: Killed old client process
Nov  7 12:00:45 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
dhclient[1715]: Error getting hardware address for "eth1": No such device
Nov  7 12:00:45 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab 
ifdown[1700]: Cannot find device "eth1"
Nov  7 12:00:45 amphora-038fb78e-923e-4143-8402-ad8dbd97f9ab systemd[1]: 
Stopped ifup for eth1.


while

1) corresponding port i

Re: [openstack-dev] [tripleo] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Correction, tomorrow 11/08/2017

On Tue, Nov 7, 2017 at 4:31 PM, Arx Cruz  wrote:

> Hello
>
> We are going to have a TripleO CI Community meeting tomorrow 11/07/2017
> at 1 pm UTC time.
> The meeting is going to happen on BlueJeans [1] and also on IRC on
> #tripleo channel.
>
> After that, we will hold Office Hours starting at 4PM UTC in case someone
> from community have any questions related to CI.
>
> Hope to see you there.
>
> 1 - https://bluejeans.com/7071866728
> 
>
>
> Kind regards,
> Arx Cruz
>
__
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] [tripleo] Please do not approve or recheck anything not related to CI alert bugs

[Alex Schultz]

Hey Folks

So we're at 24+ hours again in the gate[0] and the queue only
continues to grow. We currently have 6 ci/alert bugs[1]. Please do not
approve of recheck anything that isn't related to these bugs.  I will
most likely need to go through the queue and abandon everything to
clear it up as we are consistently hitting timeouts on various jobs
which is preventing anything from merging.

Thanks,
-Alex

[0] http://zuulv3.openstack.org/
[1] 
https://bugs.launchpad.net/tripleo/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=ci+alert&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search

__
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] [tripleo] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 11/07/2017 at
1 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/7071866728



Kind regards,
Arx Cruz
__
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] Unable to communicate with an instance

[rk_1218_live]

Hi

I created an instance using OpenStack.
Then, we set up Floating IP and added a rule enabling ping command and 
ssh command.

However, it can not communicate with the instance.
As I looked it up, the DHCP agent was not running on the Compute node. 
Also, the OpenvSwitch agent was not started.

However, on the Controller node, the DHCP agent was running.
In order to communicate with an instance, what kind of setting should be 
made to the Compute node?

DHCP agent, OpenvSwitch agent setting method is not clear well.

Could you give me a professor?

Thanks.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [watcher] Watcher weekly team meeting cancelled on November 8th

[Alexander Chadin]

Watcher team,

We will cancel the coming weekly meeting due to Sydney Summit.

Best Regards,
__
Alexander Chadin



signature.asc
Description: Message signed with OpenPGP
__
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