[issue44407] A "Coroutines and Tasks" code example needs "asyncio.run(main())"

[Atsushi Sakai]

New submission from Atsushi Sakai :

This is very small documentation improvement proposal.

In the "Coroutines and Tasks" doc, the code example after "Let’s modify the 
above example and run two say_after coroutines concurrently:" is missing 
"asyncio.run(main())" at the end of the code example:

async def main():
task1 = asyncio.create_task(
say_after(1, 'hello'))

task2 = asyncio.create_task(
say_after(2, 'world'))

print(f"started at {time.strftime('%X')}")

# Wait until both tasks are completed (should take
# around 2 seconds.)
await task1
await task2

print(f"finished at {time.strftime('%X')}")

--
assignee: docs@python
components: Documentation
messages: 395728
nosy: AtsushiSakai, docs@python
priority: normal
severity: normal
status: open
title: A "Coroutines and Tasks" code example needs "asyncio.run(main())"
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44407>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[Yahoo-eng-team] [Bug 1645306] [NEW] typo in api-paste.ini parameter

[Atsushi SAKAI]

Public bug reported:

Following line uses "olso_config_project"
  
https://github.com/openstack/nova/blame/f57cc519fde2f177920ce88b8a3ef0618d1419b0/nova/api/openstack/placement/deploy.py#L42

it should be oslo_config_project
 
https://github.com/openstack/nova/blob/f57cc519fde2f177920ce88b8a3ef0618d1419b0/etc/nova/api-paste.ini#L75

** Affects: nova
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1645306

Title:
  typo in api-paste.ini parameter

Status in OpenStack Compute (nova):
  New

Bug description:
  Following line uses "olso_config_project"

https://github.com/openstack/nova/blame/f57cc519fde2f177920ce88b8a3ef0618d1419b0/nova/api/openstack/placement/deploy.py#L42

  it should be oslo_config_project
   
https://github.com/openstack/nova/blob/f57cc519fde2f177920ce88b8a3ef0618d1419b0/etc/nova/api-paste.ini#L75

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1645306/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1606381] Re: API-REF LBaaS v2 API version mixed with LBaaS v1 API

[Atsushi SAKAI]

API-Ref issue

** Project changed: openstack-manuals => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1606381

Title:
  API-REF LBaaS v2 API version mixed with LBaaS v1 API

Status in neutron:
  New

Bug description:
  Somehow the LBaaS v2 API docs got merged/mixed with the LBaaS v1 API
  docs.  Previously there were two sections, one for the deprecated
  LBaaSv1 API and one for the LBaaSv2 API.

  
  
http://developer.openstack.org/api-ref/networking/v2-ext/index.html#lbaas-1-0-deprecated-lb-vips-health-monitors-pools-members

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1606381/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1602113] [NEW] Needs to point Image Service API documention

[Atsushi SAKAI]

Public bug reported:

Need to point the API documentation. or describe in api-ref itself.


Image metadata is updated by passing HTTP headers prefixed with one of the 
strings x-image-meta- or x-image-meta-property-. See the API documentation for 
details.

http://developer.openstack.org/api-ref/image/v1/index.html?expanded=update-image-detail#update-image

** Affects: glance
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1602113

Title:
  Needs to point Image Service API documention

Status in Glance:
  New

Bug description:
  Need to point the API documentation. or describe in api-ref itself.

  
  Image metadata is updated by passing HTTP headers prefixed with one of the 
strings x-image-meta- or x-image-meta-property-. See the API documentation for 
details.
  
  
http://developer.openstack.org/api-ref/image/v1/index.html?expanded=update-image-detail#update-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1602113/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1587847] Re: flavorRef is missing from the parameter list of Resize server

[Atsushi SAKAI]

This is api-ref for nova issue.

** Project changed: openstack-api-site => nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1587847

Title:
  flavorRef is missing from the parameter list of Resize server

Status in OpenStack Compute (nova):
  New

Bug description:
  According to the example Change administrative password has a parameter 
called "flavorRef".
  This "flavorRef" parameter is not listed in the Parameter list of Change 
administrative password in the web API reference [1] and not mentioned in 
Chapter 4.4.20 of the pdf API reference [2].
  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html#changePassword
  [2]: http://api.openstack.org/api-ref-guides/bk-api-ref.pdf

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1587847/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [api] [senlin] [keystone] [ceilometer] [telemetry] Questions about api-ref launchpad bugs

[Atsushi SAKAI]

Anne
　
　I move and clean up api-site issues as far as I can do.
  But it still remain 36 open bugs. 
  mainly  WADL, INCOMPLETE status, FIX COMMITED status,
  and too many project issue (like 1390528, 1390523 etc)
  Would you check it?

Thanks
Atsushi SAKAI

On Wed, 11 May 2016 10:04:06 -0500
Anne Gentle <annegen...@justwriteclick.com> wrote:

> On Wed, May 11, 2016 at 8:12 AM, Atsushi SAKAI <sak...@jp.fujitsu.com>
> wrote:
> 
> > Anne
> > Augustina
> >
> >   Thank you for description and help.
> >
> >   I will clean up launchpad api-site within this week at first.
> >   Since just around 150 issues and many issues are tagged it already.
> >   I can manually move most of the issues.
> >   Does any problem exist for this method?
> >
> >
> Sounds good to me. I hadn't found a script, so a manual move is fine, and
> if you're able then please go for it. :)
> 
> 
> >   Then I will do it for remaining api-ref migration issues.
> >
> 
> Sounds good. For any tooling issues, use the
> https://bugs.launchpad.net/openstack-doc-tools tracker.
> 
> Thanks!
> Anne
> 
> 
> >
> > Thanks
> > Atsushi SAKAI
> >
> >
> >
> >
> >
> > On Tue, 10 May 2016 07:53:19 -0500
> > Anne Gentle <annegen...@justwriteclick.com> wrote:
> >
> > > Great questions, so I'm copying the -docs and -dev lists to make sure
> > > people know the answers.
> > >
> > > On Tue, May 10, 2016 at 5:14 AM, Atsushi SAKAI <sak...@jp.fujitsu.com>
> > > wrote:
> > >
> > > > Hello Anne
> > > >
> > > >   I have several question when I am reading through etherpad's (in
> > > > progress).
> > > >   It would be appreciated to answer these questions.
> > > >
> > > > 1)Should api-ref launchpad **bugs** be moved to each modules
> > > >   (like keystone, nova etc)?
> > > >   Also, this should be applied to moved one's only or all components?
> > > >(compute, baremetal Ref.2)
> > > >
> > > >   Ref.
> > > > https://etherpad.openstack.org/p/austin-docs-newtonplan
> > > > API site bug list cleanup: move specific service API ref bugs to
> > > > project's Launchpad
> > > >
> > > >   Ref.2
> > > > http://developer.openstack.org/api-ref/compute/
> > > > http://developer.openstack.org/api-ref/baremetal/
> > >
> > >
> > > Yes! I definitely got agreement from nova team that they want them. Does
> > > anyone have a Launchpad script that could help with the bulk
> > filter/export?
> > > Also, are any teams concerned about taking on their API reference bugs?
> > > Let's chat.
> > >
> > >
> > > >
> > > >
> > > > 2)Status of API-Ref
> > > >   a)Why keystone and senlin are no person at this moment?
> > > >
> > > >
> > > >
> > > Keystone -- after the Summit, keystone had someone sign up [1], but
> > sounds
> > > like we need someone else. Brant, can you help us find someone?
> > >
> > > Senlin -- Qiming Teng had asked a lot of questions earlier in the process
> > > and tested the instructions. Qiming had good concerns about personal
> > > bandwidth limits following along with all the changes. Now that it's
> > > settled, I'll follow up (and hoping the senlin team is reading the list).
> > >
> > >
> > > >   b)What is your plan for sahara and ceilometer?
> > > >  (It seems already exist the document.)
> > > >
> > >
> > > Yes, these are two I had seen already have RST, but they do not use the
> > > helpful Sphinx extensions.
> > >
> > > Sahara -- Mike McCune, we should chat about the plans. Are you okay with
> > > moving towards the common framework and editing the current RST files to
> > > use the rest_method and rest_parameters Sphinx directives?
> > >
> > > Ceilometer -- sorry, Julien, I hadn't reached out individually to you.
> > > Could you let me know your plans for the RST API reference docs?
> > >
> > >
> > > >   c)When is the table's status changed to "Done"?
> > > >  nova (compute) and ironic (baremetal) seems first patch merged
> > > >  and see the document already.
> > > >
> > >
> > > I'll change those two to Done.
> > >
> > > Thanks for asking -
> > > Anne
> > >
> > >
> > > >
> > > >
> > > >   Ref.
> > > > [1]
> > > >
> > https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Atsushi SAKAI
> > > >
> > >
> > >
> > >
> > > --
> > > Anne Gentle
> > > www.justwriteclick.com
> >
> >
> > --
> > Atsushi SAKAI <sak...@jp.fujitsu.com>
> >
> 
> 
> 
> -- 
> Anne Gentle
> www.justwriteclick.com


-- 
Atsushi SAKAI <sak...@jp.fujitsu.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

[Yahoo-eng-team] [Bug 1486127] Re: Support RBAC neutron-client changes.

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1486127

Title:
  Support RBAC neutron-client changes.

Status in neutron:
  Confirmed

Bug description:
  https://review.openstack.org/205482
  commit 22c84927d133158c9de429ba1b9dbcd1d077d773
  Author: Ramanjaneya 
  Date:   Fri Jul 24 15:51:53 2015 +0530

  Support RBAC neutron-client changes.
  
  This patch adds the command line support for RBAC work.
  
  DocImpact
  APIImpact
  Partially-Implements: blueprint rbac-networks
  Co-Authored-By: dongfeng 
  
  Change-Id: I00c6b84b3f7d810f137ce05c0cd936dc194d9708

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486127/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1481600] Re: Remove Catalog Index Service

[Atsushi SAKAI]

** Project changed: openstack-api-site => glance

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1481600

Title:
  Remove Catalog Index Service

Status in Glance:
  Triaged

Bug description:
  https://review.openstack.org/197043
  commit feb927c8a11813c2cd4fbb73b2561a73e281f1aa
  Author: Louis Taylor 
  Date:   Tue Jun 30 12:19:34 2015 +

  Remove Catalog Index Service
  
  The Catalog Index Service added in the kilo cycle has been split into a 
new
  project named searchlight. This code now lives in a seperate repository:
  
  https://git.openstack.org/openstack/searchlight
  
  For more information about the split, see the governance change:
  I8b44aac03585c651ef8d5e94624f64a0ed2d10b2
  
  DocImpact
  UpgradeImpact
  APIImpact
  
  Change-Id: I239ac9e32857f6a728f40c169e773ee977cca3ca

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1481600/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1408112] Re: Update documentation for port does not show how to remove dhcp_extra_opt

[Atsushi SAKAI]

** Tags added: api-ref

** Project changed: openstack-api-site => neutron

** Changed in: neutron
Milestone: mitaka => None

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1408112

Title:
  Update documentation for port does not show how to remove
  dhcp_extra_opt

Status in neutron:
  Confirmed

Bug description:
  The manual shows how to add dhcp_extra_opts but not have to unset them

  Need to add an example

  {
"port":
{
 "extra_dhcp_opts": [{"opt_value": null, "opt_name": "33"}]
  }
  }

  ---
  Built: 2014-08-11T21:06:30 00:00
  git SHA: 3302e05316e88d42067e3c1555df34371043999d
  URL: 
http://docs.openstack.org/api/openstack-network/2.0/content/extra-dhc-opt-ext-update.html
  source File: 
file:/home/jenkins/workspace/netconn-api-tox-doc-publishdocs/v2.0/section_neutron-ext-extra-dhcp-options.xml
  xml:id: extra-dhc-opt-ext-update

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1408112/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1505776] Re: Validate src_ip_adress, dest_ip_address and ip_version

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1505776

Title:
  Validate src_ip_adress, dest_ip_address and ip_version

Status in neutron:
  Confirmed
Status in openstack-manuals:
  Fix Released

Bug description:
  https://review.openstack.org/215768
  commit 29c51879683087e8ea486aaa9866bbce1f47a15c
  Author: Sean M. Collins 
  Date:   Mon Aug 10 15:24:52 2015 -0400

  Validate src_ip_adress, dest_ip_address and ip_version
  
  The FwaaS API should not allow the creation of firewall rules where
  the ip_version is set to 4, but the source or destination IPs are IPv6
  addresses
  
  APIImpact
  DocImpact
  
  Closes-Bug: #1487599
  
  Change-Id: Iad680996a47adcf27f9dc7e0bc0fea924fff4f9f

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1505776/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1551368] Re: L7 capability extension implementation for lbaas v2

[Atsushi SAKAI]

The API-Ref is changed from doc to each project (neutron)

** Changed in: neutron
   Status: Invalid => Confirmed

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1551368

Title:
  L7 capability extension implementation for lbaas v2

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/148232
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 254190b3051453f823dbdf1826f1a6b984c57164
  Author: Evgeny Fedoruk 
  Date:   Mon Jan 19 03:47:39 2015 -0800

  L7 capability extension implementation for lbaas v2
  
  Including extension modifications
  Including db model modifications
  Including alembic migration
  Including new driver managers for l7 rules and policies
  Inclufing logging_noop driver implementation
  Including unit testing
  Including Octavia driver updates
  
  DocImpact
  APIImpact
  Change-Id: I8f9535ebf28155adf43ebe046d2dbdfa86c4d81b
  Implements: blueprint lbaas-l7-rules
  Co-Authored-By: Evgeny Fedoruk 
  Co-Authored-By: Stephen Balukoff 

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1551368/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1548511] Re: Shared pools support

[Atsushi SAKAI]

The API-Ref is changed from doc to each project (neutron)
  

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1548511

Title:
  Shared pools support

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid

Bug description:
  https://review.openstack.org/218560
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 4f3cf154829fcd69ecf3fa7f4e49f82d0104a4f0
  Author: Stephen Balukoff 
  Date:   Sat Aug 29 02:51:09 2015 -0700

  Shared pools support
  
  In preparation for L7 switching functionality, we need to
  reduce the rigidity of our model somewhat and allow pools
  to exist independent of listeners and be shared by 0 or
  more listeners. With this patch, pools are now associated
  with loadbalancers directly, and there is now a N:M
  relationship between listeners and pools.
  
  This patch does alter the Neutron LBaaS v2 API slightly,
  but all these changes are backward compatible. Nevertheless,
  since Neutron core dev team has asked that any API changes
  take place in an extension, that is what is being done in
  this patch.
  
  This patch also updates the reference namespace driver to
  render haproxy config templates correctly given the pool
  sharing functionality added with the patch.
  
  Finally, the nature of shared pools means that the usual
  workflow for tenants can be (but doesn't have to be)
  altered such that pools can be created before listeners
  independently, and assigned to listeners as a later step.
  
  DocImpact
  APIImpact
  Partially-Implements: blueprint lbaas-l7-rules
  Change-Id: Ia0974b01f1f02771dda545c4cfb5ff428a9327b4

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1548511/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1550559] Re: Qos policy RBAC DB setup and migration

[Atsushi SAKAI]

The API-Ref is changed from doc to each project (neutron)


** Changed in: neutron
   Status: Invalid => Confirmed

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1550559

Title:
  Qos policy RBAC DB setup and migration

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid
Status in openstack-manuals:
  Fix Released

Bug description:
  https://review.openstack.org/250081
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit aeaf77a5295080a3010a2e9c32e24f47c8cc73cc
  Author: Haim Daniel 
  Date:   Wed Nov 25 18:49:45 2015 -0500

  Qos policy RBAC DB setup and migration
  
  This patch implements a new database model required for the
  qos-policy RBAC support. In addition it migrates the current qos-policy
  'shared' attribute to leverage the new 'qospolicyrbacs' table.
  
  'shared' is no longer a property of the QosPolicy DB model. Its status
  is based on the tenant ID of the API caller. From an API perspective the
  logic remains the same - tenants will see qos-policies as 'shared=True'
  in case the qos-policy is shared with them). However, internal callers
  (e.g. plugins, drivers, services) must not check for the 'shared'
  attribute on qos-policy db objects any more.
  
  DocImpact
  APIImpact
  
  Blueprint: rbac-qos
  Related-bug: #1512587
  
  Change-Id: I1c59073daa181005a3e878bc2fe033a0709fbf31

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1550559/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1565631] Re: [Shared images] is missing and wrong parameter

[Atsushi SAKAI]

** Project changed: openstack-api-site => glance

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1565631

Title:
  [Shared images] is missing and wrong parameter

Status in Glance:
  Confirmed

Bug description:
  Response parameters in List shared images [1] miss "shared_images" parameter.
  And type of "image_id" parameter is "xsd:string", this value is wrong. It 
should be change "csapi:UUID".

  [1] http://developer.openstack.org/api-ref-
  image-v1.html#listSharedImages-v1

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1565631/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1537121] Re: Add functionality to define requests without body

[Atsushi SAKAI]

** Project changed: openstack-api-site => glance

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1537121

Title:
  Add functionality to define requests without body

Status in Glance:
  Confirmed

Bug description:
  https://review.openstack.org/207150
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 9b430f99518e10ae263bedec3062408af332068c
  Author: Niall Bunting 
  Date:   Tue Jul 28 15:05:10 2015 +

  Add functionality to define requests without body
  
  This allows functions that do not accept bodies to define this in the
  router file. As currently many requests will cause a 500 if a body is
  supplied when the API request does not expect it.
  
  This currently only affects the core parts of the v2 api, that is,
  calls to v2/images and v2/schemas. It does not cover the "tasks" API
  or the metadefs api as I was keeping this patch concise. As this
  does not affect the behaviour if not included this makes no change to
  the metadefs api behaviour.
  
  DocImpact
  
  Partial-Bug: 1475647
  
  Change-Id: Ieb510e5516128078d40d39fd9b4f339ce64e10e7

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1537121/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1532220] Re: OS-EP-FILTER extension missing

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

** Tags added: api-ref

** Summary changed:

- OS-EP-FILTER extension missing
+ [api-ref]OS-EP-FILTER extension missing

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1532220

Title:
  [api-ref]OS-EP-FILTER extension missing

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  Missing OS-EP-FILTER extension for Identity v3:
  http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
  api-v3-os-ep-filter-ext.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1532220/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1532222] Re: OS-FEDERATION extension missing

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

** Tags added: api-ref

** Summary changed:

- OS-FEDERATION extension missing
+ [api-ref]OS-FEDERATION extension missing

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/153

Title:
  [api-ref]OS-FEDERATION extension missing

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  The OS-FEDERATION extension is missing for Identity v3:
  http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
  api-v3-os-federation-ext.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/153/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1506149] Re: Bodies that are not dicts or lists return 400

[Atsushi SAKAI]

The API-REF is canged from doc to each project (glance)

** Project changed: openstack-api-site => glance

** Changed in: glance
Milestone: mitaka => None

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1506149

Title:
  Bodies that are not dicts or lists return 400

Status in Glance:
  Confirmed
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/204138
  commit d8ca5c20c51a205624b3e815726e5c103a30b632
  Author: Niall Bunting 
  Date:   Tue Jul 21 15:22:06 2015 +

  Bodies that are not dicts or lists return 400
  
  Type errors that are encountered due to unexpected
  types being passed in now get a 400 'Body format is
  invalid'. This hardens the glance api from other types.
  
  ApiImpact
  DocImpact
  
  Closes-Bug: 1476695
  Closes-Bug: 1476253
  Change-Id: Ieee0662f67c800b2b3c07c6a8b7877939cf9e1fe

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1506149/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1471032] Re: Support Basic Address Scope CRUD as extensions

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Tags added: api-ref

** Summary changed:

- Support Basic Address Scope CRUD as extensions
+ [api-ref]Support Basic Address Scope CRUD as extensions

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1471032

Title:
  [api-ref]Support Basic Address Scope CRUD as extensions

Status in neutron:
  Confirmed

Bug description:
  https://review.openstack.org/189741
  commit cbd95318ad6c44e72a3aa163f7a399353c8b4458
  Author: vikram.choudhary 
  Date:   Tue Jun 9 19:55:59 2015 +0530

  Support Basic Address Scope CRUD as extensions
  
  This patch adds the support for basic address scope CRUD.
  Subsequent patches will be added to use this address scope
  on subnet pools.
  
  DocImpact
  APIImpact
  
  Co-Authored-By: Ryan Tidwell 
  Co-Authored-By: Numan Siddique 
  Change-Id: Icabdd22577cfda0e1fbf6042e4b05b8080e54fdb
  Partially-implements:  blueprint address-scopes

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1471032/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1552015] Re: Support cleanup of tenant resources with a single API call

[Atsushi SAKAI]

The API-Ref is changed from doc to each project (neutron).

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1552015

Title:
  Support cleanup of tenant resources with a single API call

Status in neutron:
  Confirmed
Status in openstack-manuals:
  Fix Released
Status in python-neutronclient:
  Invalid

Bug description:
  https://review.openstack.org/276541
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/python-neutronclient" is set up so that we directly 
report the documentation bugs against it. If this needs changing, the 
docimpact-group option needs to be added for the project. You can ask the 
OpenStack infra team (#openstack-infra on freenode) for help if you need to.

  commit 88fbd3870cf3872fb0c9b4269503c62458664b3b
  Author: John Davidge 
  Date:   Mon Feb 15 10:02:54 2016 -0800

  Support cleanup of tenant resources with a single API call
  
  The addition of the 'neutron purge' command allows cloud admins
  to conveniently delete multiple neutron resources associated
  with a given tenant.
  
  The command will delete all supported resources provided that
  they can be deleted (not in use, etc) and feedback the amount
  of each resource deleted to the user. A completion percentage
  is also given to keep the user informed of progress.
  
  Currently supports deletion of:
  
  Networks
  Subnets (implicitly)
  Routers
  Ports (including router interfaces)
  Floating IPs
  Security Groups
  
  This feature can be easily extended to support more resource
  types in the future.
  
  DocImpact: Update API documentation to describe neutron-purge usage
  
  Change-Id: I5a366d3537191045eb53f9cccd8cd0f7ce54a63b
  Closes-Bug: 1511574
  Partially-Implements: blueprint tenant-delete

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552015/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1547271] Re: Preserve subnet_create behavior in presence of subnet pools

[Atsushi SAKAI]

The API-Ref is moved from doc to each project (neutron)


** Changed in: neutron
   Status: Invalid => Confirmed

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1547271

Title:
  Preserve subnet_create behavior in presence of subnet pools

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/279378
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit d38aeade9db7169955b4524a5fc8d814067dec15
  Author: Armando Migliaccio 
  Date:   Thu Feb 11 20:56:20 2016 -0800

  Preserve subnet_create behavior in presence of subnet pools
  
  The development of the auto_allocate extension, which relies on subnet
  pools, revealed some discrepancies in the behavior of the subnet_create
  API: if a user specifies a cidr on subnet_create like he/she is used
  to, the API outcome changes in presence of default subnetpools. For
  instance the command 'neutron subnet-create network ' returns a
  subnet associated to a pool, if a default pool exists, but it does not
  otherwise. At the same time, attempting to create a subnet without
  passing any detail but the ip version also behaves unexpectedly
  depending on the state of the system.
  
  Whilst this could be considered convenient in some circumstances,
  it is problematic for a couple of reasons: a) it breaks a well defined
  contract (backward compat of the subnet-create command), and b) it
  leads to ambiguity of the API.
  
  This patch restores the semantic of the subnet_create API where it is
  mandatory to specify CIDR/IP version regardless of the conditions
  under which the request is issued. On the other hand, associating
  subnets to subnet pools will have to be more prescriptive, and
  require the user to explicitly state his/her intentions when creating
  the subnet: if a user does want a subnet (CIDR) to belong to a subnet
  pool, he/she will have to state so, either by specifying a subnetpool
  name/uuid, or by asking for a default one.
  
  This will be tackled as a follow-up, especially in order to address the
  needs of prefix delegation which currently rely on the ambiguous
  behavior that this patch is fixing.
  
  Closes-bug: 1545199
  
  DocImpact: subnetpools can be used to simplify IPAM, and can be specified
  during subnet creation.
  
  Change-Id: Idf516ed9db24d779742cdff0584b48182a8502d6

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1547271/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1564887] Re: Neutron v2 Layer-3 extension - `routes` attribute not helpful

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Tags added: api-ref

** Summary changed:

- Neutron v2 Layer-3 extension - `routes` attribute not helpful
+ [api-ref]Neutron v2 Layer-3 extension - `routes` attribute not helpful

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1564887

Title:
  [api-ref]Neutron v2 Layer-3 extension - `routes` attribute not helpful

Status in neutron:
  In Progress

Bug description:
  In all the router responses, you see a `routes` attribute. This is the
  explanation for it:

  routes  plain   xsd:listThe extra routes configuration for L3
  router.

  1. What exactly is the structure of this value? "xsd:list" means nothing to 
me. Are there nested objects, nested strings?
  2. The description doesn't explain how a route functions.

  Also, how do routes get set on routers? It's not included as an input
  param for POST or PUT operations.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1564887/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1516073] Re: Replace subnetpool config options with admin-only API

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1516073

Title:
  Replace subnetpool config options with admin-only API

Status in neutron:
  Confirmed
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/230983
  commit 6ee91e56c84ea6e930369f8649f1d2b50096cb80
  Author: John Davidge 
  Date:   Thu Oct 1 20:37:34 2015 +0100

  Replace subnetpool config options with admin-only API
  
  This patch adds a new boolean 'is_default' property to subnetpools. This
  allows the admin to set the default v4/v6 subnetpools via the API rather
  than the existing neutron.conf options - which are deprecated by this 
patch.
  
  Only one subnetpool per IP family can be set to default.
  
  DocImpact
  ApiImpact
  
  Co-Authored-By: Carl Baldwin 
  
  Change-Id: I5daba2347cfb91fac0b155b2c1b459ee7d9e4505
  Closes-Bug: 1501328

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1516073/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1364221] Re: IPSec site connections in OpenStack Networking API v2.0 (neutron) Reference - API v2.0 (neutron) and extensions

[Atsushi SAKAI]

The API-ref issue is moved from doc to each project (neutron).

** Project changed: openstack-api-site => neutron

** Changed in: neutron
Milestone: liberty => None

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1364221

Title:
  IPSec site connections in OpenStack Networking API v2.0 (neutron)
  Reference  - API v2.0 (neutron) and extensions

Status in neutron:
  Confirmed
Status in python-neutronclient:
  Won't Fix

Bug description:
   peer_id attribute  can be IPv4/IPv6 address as per design now ,but in notes 
mentioned as it can be IPv4/IPv6 address, e-mail address, key id, or FQDN.
  ---
  Built: 2014-08-11T21:06:27 00:00
  git SHA: 3302e05316e88d42067e3c1555df34371043999d
  URL: 
http://docs.openstack.org/api/openstack-network/2.0/content/vpnaas_ext_ops_ipsec_site_connection.html
  source File: 
file:/home/jenkins/workspace/netconn-api-tox-doc-publishdocs/v2.0/section_neutron-ext-vpnaas.xml
  xml:id: vpnaas_ext_ops_ipsec_site_connection

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1364221/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1570892] Re: Openswan/Libreswan: support sha256 for auth algorithm

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Summary changed:

- Openswan/Libreswan: support sha256 for auth algorithm
+ [api-ref]Openswan/Libreswan: support sha256 for auth algorithm

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1570892

Title:
  [api-ref]Openswan/Libreswan: support sha256 for auth algorithm

Status in neutron:
  Confirmed

Bug description:
  https://review.openstack.org/303684
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit b73e1002555cfa70ccfea8ffe685672c0b679212
  Author: nick.zhuyj 
  Date:   Fri Apr 8 23:48:33 2016 -0500

  Openswan/Libreswan: support sha256 for auth algorithm
  
  Add support for sha256 as it is requirement from customer.
  Currently, there is no ike/esp fields in strongswan ipsec.conf
  template, so by default. sha256 is used. But for openswan auth
  algorithm is get from configuration, so only sha1 is supported.
  This patch enable Openswan/Libreswan to support sha256.
  
  Note: this change is DocImpact and APIImpact
  
  Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2
  Closes-Bug: #1567846

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570892/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1572168] Re: Missing response parameter tables identity admin API

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

** Summary changed:

- Missing response parameter tables identity admin API
+ [api-ref]Missing response parameter tables identity admin API

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1572168

Title:
  [api-ref]Missing response parameter tables identity admin API

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-listTenants
  
http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-showTenantByName
  
http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-showTenantById
  
http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-listRolesForUserOnTenant

  The above APIs do not have response parameter table. They must be
  documented.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1572168/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1566607] Re: [Show user details] miss request parameter

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

** Summary changed:

- [Show user details] miss request parameter
+ [api-ref][Show user details] miss request parameter

** Tags added: api-ref

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1566607

Title:
  [api-ref][Show user details] miss request parameter

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  Show user details [1] miss parameters: name, enabled, email, id, user
  and username

  [1]http://developer.openstack.org/api-ref-identity-admin-v2.html
  #admin-showUser

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1566607/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1418635] Re: Neutron API reference is inconsistent and differs from implementation

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Summary changed:

- Neutron API reference is inconsistent and differs from implementation
+ [api-ref]Neutron API reference is inconsistent and differs from implementation

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1418635

Title:
  [api-ref]Neutron API reference is inconsistent and differs from
  implementation

Status in neutron:
  Confirmed

Bug description:
  I'm implementing modules for SaltStack (not yet on GitHub) to create entities 
in OpenStack Neutron and came across quite a few problems 
  with the API documentation:

  * Link "Filtering and Column Selection" to 
http://docs.openstack.org/api/openstack-network/2.0/content/filtering.html
    404s

  * Section http://developer.openstack.org/api-ref-
  networking-v2.html#subnets

    * "POST /v2.0/subnets" aka "Create subnet"
  - 'id' is listed to be an optional parameter but the Neutron-API in 
Icehouse refuses to set a user-selected ID
  - parameters 'dns_nameservers' and 'host_routes' missing from 
documentation (undocumented extensions?)

    * "GET /v2.0/subnets" aka "List subnets"
  - can't filter by "allocation_pools" or "enable_dhcp"

    * "PUT /v2.0/subnets/​{subnet_id}​" aka "Update subnet"
  - parameters "allocation_pools", "network_id", "tenant_id", "id" listed 
as optional request parameters but Neutron-API in Icehouse returns 
"Cannot update read-only attribute $PARAMETER"

  * Section http://developer.openstack.org/api-ref-
  networking-v2.html#networks

    * "GET /v2.0/networks" aka "List networks"
  - parameter "shared" is ignored as a filter

  * Section http://developer.openstack.org/api-ref-
  networking-v2.html#layer3

    * "POST /v2.0/routers" aka "Create router"
  - Description states "router:external" and "external_gateway_info" are 
valid request parameters but they're not listed in the table of 
request parameters
  - What's the parameter router described as "A router object." supposed 
to be? A router object in JSON/XML notation inside a router object in 
JSON/XML notation?

  I'll probably add more when implementing functions for managing
  routers in Neutron.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1418635/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1552077] Re: Use network RBAC feature for external access

[Atsushi SAKAI]

The API-Ref is changed from api-site to project (neutron)

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

** Changed in: neutron
   Status: Invalid => Confirmed

** Summary changed:

- Use network RBAC feature for external access
+ [api-ref]Use network RBAC feature for external access

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1552077

Title:
  [api-ref]Use network RBAC feature for external access

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid

Bug description:
  https://review.openstack.org/282295
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 49b4dd3478d782aee4260033825aa6b47eaf644a
  Author: Kevin Benton 
  Date:   Fri Feb 19 03:34:27 2016 -0800

  Use network RBAC feature for external access
  
  This allows access to external networks to be controlled via the
  RBAC framework added during Liberty with a new 'access_as_external'
  action.
  
  A migration adds all current external networks to the RBAC policies
  table with a wildcard indicating that all tenants can access the network
  as RBAC.
  
  Unlike the conversion of shared networks to RBAC, the external table
  is left in the DB to avoid invasive changes throughout the codebase
  to calculate the flag relative to the caller. So the current 'external'
  flag is used throughout the code base as it previously was for wiring
  up floating IPs, router gateway ports, etc. Then the RBAC entries are
  only referenced when determining what networks to show the tenants.
  
  API Behavior:
   * Marking a network as 'external' will automatically create a wildcard
 entry that allows that network to be accessed by all tenants.
   * An external network may have all of its RBAC entries deleted and then
 only an admin will be able to attach to it.
   * An RBAC 'access_as_external' entry cannot be deleted if it is required
 for a tenant that currently has a router attached to that network.
   * Creating an 'access_as_external' RBAC entry will automatically convert
 the network into an external network. (This is to enable a workflow
 where a private external network is never visible to everyone.)
   * The default policy.json will prevent a non-admin from creating wildcard
 'access_as_external' RBAC entries to align with the current default 
policy
 we have on setting the 'external' field on the network to prevent 
poluting
 everyone else's network lists.
   * The default policy.json will allow a tenant to create an
 'access_as_external' RBAC entry to allow specific tenants
 (including itself) the ability to use its network as an external 
network.
  
  Closes-Bug: #1547985
  DocImpact: External networks can now have access restricted to small 
subsets
 of tenants
  APIImpact: 'access_as_external' will be allowed as an action in the RBAC
 API for networks
  Change-Id: I4d8ee78a9763c58884e4fd3d7b40133da659cd61

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552077/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1382268] Re: Add notification for server group operations

[Atsushi SAKAI]

** Project changed: openstack-api-site => nova

** Summary changed:

- Add notification for server group operations
+ [api-ref]Add notification for server group operations

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1382268

Title:
  [api-ref]Add notification for server group operations

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  https://review.openstack.org/107954
  commit daf278c0c8b6cc917b84f514fec65758adf17028
  Author: Jay Lau 
  Date:   Thu Oct 16 15:08:32 2014 -0400

  Add notification for server group operations
  
  Currently, there is no notification when create/update/delete
  server groups, this caused some 3rd party client cannot know
  when those operations are finished.
  
  The fix was adding notifications for those operations.
  
  DocImpact
  The wiki page https://wiki.openstack.org/wiki/SystemUsageData
  needs to be updated once this patch was merged.
  
  Change-Id: Ia1f4a6752668ddb73ebb8faf525b58a28d183754
  Closes-Bug: #1343200

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1382268/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1553332] Re: API documentation missing for neutron rbac-policies

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1553332

Title:
  API documentation missing for neutron rbac-policies

Status in neutron:
  In Progress

Bug description:
  https://specs.openstack.org/openstack/neutron-specs/specs/liberty
  /rbac-networks.html#rest-api-impact doesn't appear to be reflected in
  the neutron API documentation, despite the fact that the spec was
  implemented (see neutron/extensions/rbac.py). I believe this should be
  included on http://developer.openstack.org/api-ref-
  networking-v2-ext.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1553332/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1553653] Re: Add a description field to all standard resources

[Atsushi SAKAI]

API-Ref is moved from doc to each project (neutron).

** Changed in: neutron
   Status: Invalid => Confirmed

** Changed in: openstack-api-site
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1553653

Title:
  Add a description field to all standard resources

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid

Bug description:
  https://review.openstack.org/269887
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 5dacbba701037200f9b0ae40c34981ecd941b41c
  Author: Kevin Benton 
  Date:   Wed Feb 10 17:00:21 2016 -0800

  Add a description field to all standard resources
  
  In order to give users and operators more flexibility in
  annotating the purpose of various Neutron resources, this patch
  adds a description field limited to 255 chars to all of the
  Neutron resources that reference the standard attribute table.
  The resource that reference the table are the following:
  security_group_rules, security_groups, ports, subnets,
  networks, routers, floatingips, subnetpools
  
  This patch adds a description table related to standard attributes
  and migrates over the existing security group description to the new
  table as well.
  
  Co-Authored-By: James Dempsey 
  
  APIImpact
  DocImpact: Adds a description field to all resources outline in
 commit message.
  Closes-Bug: #1483480
  Change-Id: I6e1ef53d7aae7d04a5485810cc1db0a8eb125953

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1553653/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1487745] Re: Neutron RBAC API and network support

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1487745

Title:
  Neutron RBAC API and network support

Status in neutron:
  Confirmed
Status in openstack-manuals:
  Won't Fix

Bug description:
  https://review.openstack.org/192555
  commit 4595899f7f2b3774dc2dac2f8dd1a085b1e7973d
  Author: Kevin Benton 
  Date:   Tue Jun 16 23:43:59 2015 -0700

  Neutron RBAC API and network support
  
  This adds the new API endpoint to create, update, and delete
  role-based access control entries. These entries enable tenants
  to grant access to other tenants to perform an action on an object
  they do not own.
  
  This was previously done using a single 'shared' flag; however, this
  was too coarse because an object would either be private to a tenant
  or it would be shared with every tenant.
  
  In addition to introducing the API, this patch also adds support to
  for the new entries in Neutron networks. This means tenants can now
  share their networks with specific tenants as long as they know the
  tenant ID.
  
  This feature is backwards-compatible with the previous 'shared'
  attribute in the API. So if a deployer doesn't want this new feature
  enabled, all of the RBAC operations can be blocked in policy.json and
  networks can still be globally shared in the legacy manner.
  
  Even though this feature is referred to as role-based access control,
  this first version only supports sharing networks with specific
  tenant IDs because Neutron currently doesn't have integration with
  Keystone to handle changes in a tenant's roles/groups/etc.
  
  DocImpact
  APIImpact
  
  Change-Id: Ib90e2a931df068f417faf26e9c3780dc3c468867
  Partially-Implements: blueprint rbac-networks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1487745/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1532223] Re: [api-ref]OS-REVOKE extension missing for Identity v3

[Atsushi SAKAI]

** Summary changed:

- OS-REVOKE extension missing for Identity v3
+ [api-ref]OS-REVOKE extension missing for Identity v3

** Project changed: openstack-api-site => keystone

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1532223

Title:
  [api-ref]OS-REVOKE extension missing for Identity v3

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  OS-REVOKE extension is missing for Identity v3:
  http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
  api-v3-os-revoke-ext.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1532223/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1517705] Re: Move federation extension into keystone core

[Atsushi SAKAI]

The api-ref is changed from api-site to keystone.

** Project changed: openstack-api-site => keystone

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1517705

Title:
  Move federation extension into keystone core

Status in OpenStack Identity (keystone):
  Confirmed
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/214775
  commit cbefe7c7b83b5f940f817adf60a4be35bd324775
  Author: Steve Martinelli 
  Date:   Sun Oct 11 03:01:05 2015 -0400

  Move federation extension into keystone core
  
  Remove federation as an extension and move it to a core resource.
  For now we leave the database migrations in the extension directory
  until we have a general policy for merging these into core.
  
  Some instances of federation constants were removed because
  they were causing a circular dependency, these can be refactored in
  a later patch.
  
  DocImpact: You should no longer run the migrations for this extension
  Implements: bp move-extensions
  
  Co-Authored-By: Nithya Renganathan 
  
  Change-Id: If5857a6ee4c7c527929069b25beab40f4c5d87e2

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1517705/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1253672] Re: update Images v2 API to include info about multilevel restricted JSON pointers

[Atsushi SAKAI]

** Project changed: openstack-api-site => glance

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1253672

Title:
  update Images v2 API to include info about multilevel restricted JSON
  pointers

Status in Glance:
  Triaged

Bug description:
  The Havana release of Glance introduces a "multiple image locations"
  option.  In order to allow the http PATCH (image-update) request to
  operate on multiple locations, the "restricted JSON pointers" used by
  the application/openstack-images-v2.1-json-patch media type has been
  expanded to allow multilevel references.

  (1) The documentation in the OpenStack Image Service API v2 Reference
  needs to be updated to reflect this.

  (2) Need to supply at least one example, either in Appendix B or in
  the image update section, illustrating how to use the multilevel
  pointer to update an image location.

  (3) Judgement call: update the image detail section to show what an
  image response looks like with multiple image locations turned on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1253672/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1524153] Re: Need to write "update user of OS-KSCRUD extension" on identity v2 API

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

** Summary changed:

- Need to write "update user of OS-KSCRUD extension" on identity v2 API
+ [api-ref]Need to write "update user of OS-KSCRUD extension" on identity v2 API

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1524153

Title:
  [api-ref]Need to write "update user of OS-KSCRUD extension" on
  identity v2 API

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  Now keystone supports "update user of OS-KSCRUD extension" on identity v2 
API, and tempest also is testing the API.
  However, the api-site doesn't contain the API description.
  So we need to write the API for API users.

  The URL is "OS-KSCRUD/users/" and the method is PATCH on
  identity v2 API.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1524153/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1526212] Re: [api-ref]Need to write "add dhcp agent to network" on Networking API

[Atsushi SAKAI]

** Summary changed:

-  Need to write "add dhcp agent to network" on Networking API
+ [api-ref]Need to write "add dhcp agent to network" on Networking API

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1526212

Title:
  [api-ref]Need to write "add dhcp agent to network" on Networking API

Status in neutron:
  Confirmed

Bug description:
  Neutron supports "add dhcp agent to network" on Networking API, and tempest 
also is testing the API.
  However, the api-site doesn't contain the API description.
  So we need to write the API for API users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526212/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1526670] Re: [api-ref]Need to write "add router to l3 agent" on Networking API

[Atsushi SAKAI]

** Summary changed:

- Need to write "add router to l3 agent" on Networking API
+ [api-ref]Need to write "add router to l3 agent" on Networking API

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1526670

Title:
  [api-ref]Need to write "add router to l3 agent" on Networking API

Status in neutron:
  Confirmed

Bug description:
  Neutron supports "add router to l3 agent" on Networking API, and tempest also 
is testing the API.
  However, the api-site doesn't contain the API description.
  So we need to write the API for API users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526670/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1526673] Re: Need to write "update agent" on Networking API

[Atsushi SAKAI]

** Project changed: openstack-api-site => neutron

** Summary changed:

- Need to write "update agent" on Networking API
+ [api-ref]Need to write "update agent" on Networking API

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1526673

Title:
  [api-ref]Need to write "update agent" on Networking API

Status in neutron:
  In Progress

Bug description:
  Neutron supports "update agent" on Networking API, and tempest also is 
testing the API.
  However, the api-site doesn't contain the API description.
  So we need to write the API for API users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526673/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1361791] Re: Allow attaching external networks based on configurable policy

[Atsushi SAKAI]

** Project changed: openstack-api-site => nova

** Summary changed:

- Allow attaching external networks based on configurable policy
+ [api-ref]Allow attaching external networks based on configurable policy

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1361791

Title:
  [api-ref]Allow attaching external networks based on configurable
  policy

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  https://review.openstack.org/112750
  commit 674954f731bf4b66356fadaa5baaeb58279c5832
  Author: Chris Yeoh 
  Date:   Fri Aug 8 11:48:17 2014 +0930

  Allow attaching external networks based on configurable policy
  
  Commit da66d50010d5b1ba1d7fc9c3d59d81b6c01bb0b0 restricted
  attaching external networks to admin clients. This patch changes
  it to a policy based check instead with the default setting being
  admin only. This allows operators to more precisely configure who
  they wish to allow to attach external networks without having to
  give them admin access
  
  Change-Id: I59e71f117f889f2abffddc36c1870ef1e0fe3711
  DocImpact: Adds network:attach_external_network policy
  Closes-Bug: #1352102

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1361791/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1523012] Re: set `is_admin` on tokens for admin project

[Atsushi SAKAI]

** Project changed: openstack-api-site => keystone

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1523012

Title:
  set `is_admin` on tokens for admin project

Status in OpenStack Identity (keystone):
  In Progress
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/240719
  commit e7023697a884759716d0a01605825a3af90d4db6
  Author: Adam Young 
  Date:   Sun Oct 11 23:15:52 2015 -0400

  set `is_admin` on tokens for admin project
  
  Adds two new configuration value:
  
  admin_project_name
  admin_project_domain_name
  
  If both values are set, and tokens requested for
  projects (only, not domains) that match both will have an
  additional value in them;  `is_admin_project=true`
  
  DocImpact
  -- Configuration changes need documentation
  APIImpact
  -- Adds optional return values in token validation calls
  SecurityImpact
  -- Should be helpful in making access control decisions
  
  Implements: blueprint is-admin-project
  Partial-Bug: #968696
  
  Change-Id: Ic9cf9862739381a30130b4be87075f726736ff88

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1523012/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1539467] Re: [Image service API v2] Incorrect description for List API

[Atsushi SAKAI]

** Tags added: api-ref

** Project changed: openstack-api-site => glance

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1539467

Title:
  [Image service API v2] Incorrect description for List API

Status in Glance:
  In Progress

Bug description:
  I 've tested this API:
  http://developer.openstack.org/api-ref-image-v2.html#listVersions-image-v2

  The description for the response of the API says:
  "This operation does not accept a request body and does not return a response 
body."

  But the API does return a response. The description should be:
  "This operation does not accept a request body."

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1539467/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1480400] Re: Documentation error for properties

[Atsushi SAKAI]

The api-ref is maintained by each module (for this case glance).
So I close for api-site ticket.

** Changed in: openstack-api-site
   Status: In Progress => Opinion

** Changed in: openstack-api-site
   Status: Opinion => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1480400

Title:
  Documentation error for properties

Status in Glance:
  In Progress
Status in openstack-api-site:
  Invalid

Bug description:
  Document: http://developer.openstack.org/api-ref-image-v2.html

  Under the image create drop down there is the following line:
  properties (Optional) plain | xsd:dict | Properties, if any, that are 
associated with the image.

  This suggests that the properties are a dict and would look like this:
  -d '{"name": "thename", "properties": {"myprop", "mydata"}}'

   this is not the case, as if you want
  to define custom properties in a curl command you do it by defining it like 
any other property eg.
  -d '{"name": "thename", "myprop": "mydata"}'

  The documentation is not clear about this distinction.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1480400/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1581666] Re: [api-ref]Broken link to filtering section in list floating IP detail operation

[Atsushi SAKAI]

** Summary changed:

- Broken link to filtering section in list floating IP detail operation
+ [api-ref]Broken link to filtering section in list floating IP detail operation

** Project changed: openstack-api-site => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1581666

Title:
  [api-ref]Broken link to filtering section in list floating IP detail
  operation

Status in neutron:
  New

Bug description:
  In repo: 
https://github.com/openstack/api-site/blob/master/api-ref/source/networking/v2-ext/layer3-ext.inc
  In operation "Show floating IP details" here 
http://developer.openstack.org/api-ref-networking-v2-ext.html#showFloatingIp

  It offers a link to filtering section which is broken. Link should
  point to :
  
https://wiki.openstack.org/wiki/Neutron/APIv2-specification#Filtering_and_Column_Selection

  The “List floating IP” operation links correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1581666/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [api] [senlin] [keystone] [ceilometer] [telemetry] Questions about api-ref launchpad bugs

[Atsushi SAKAI]

Anne
Augustina

  Note.
Sorry for duplicate posting for openstack-docs.
Since I failed to post to openstack-dev.

  Thank you for description and help.

  I will clean up launchpad api-site within this week at first.
  Since just around 150 issues and many issues are tagged it already.
  I can manually move most of the issues.
  Does any problem exist for this method?

  Then I will do it for remaining api-ref migration issues.

Thanks
Atsushi SAKAI

  



On Tue, 10 May 2016 07:53:19 -0500
Anne Gentle <annegen...@justwriteclick.com> wrote:

> Great questions, so I'm copying the -docs and -dev lists to make sure
> people know the answers.
> 
> On Tue, May 10, 2016 at 5:14 AM, Atsushi SAKAI <sak...@jp.fujitsu.com>
> wrote:
> 
> > Hello Anne
> >
> >   I have several question when I am reading through etherpad's (in
> > progress).
> >   It would be appreciated to answer these questions.
> >
> > 1)Should api-ref launchpad **bugs** be moved to each modules
> >   (like keystone, nova etc)?
> >   Also, this should be applied to moved one's only or all components?
> >(compute, baremetal Ref.2)
> >
> >   Ref.
> > https://etherpad.openstack.org/p/austin-docs-newtonplan
> > API site bug list cleanup: move specific service API ref bugs to
> > project's Launchpad
> >
> >   Ref.2
> > http://developer.openstack.org/api-ref/compute/
> > http://developer.openstack.org/api-ref/baremetal/
> 
> 
> Yes! I definitely got agreement from nova team that they want them. Does
> anyone have a Launchpad script that could help with the bulk filter/export?
> Also, are any teams concerned about taking on their API reference bugs?
> Let's chat.
> 
> 
> >
> >
> > 2)Status of API-Ref
> >   a)Why keystone and senlin are no person at this moment?
> >
> >
> >
> Keystone -- after the Summit, keystone had someone sign up [1], but sounds
> like we need someone else. Brant, can you help us find someone?
> 
> Senlin -- Qiming Teng had asked a lot of questions earlier in the process
> and tested the instructions. Qiming had good concerns about personal
> bandwidth limits following along with all the changes. Now that it's
> settled, I'll follow up (and hoping the senlin team is reading the list).
> 
> 
> >   b)What is your plan for sahara and ceilometer?
> >  (It seems already exist the document.)
> >
> 
> Yes, these are two I had seen already have RST, but they do not use the
> helpful Sphinx extensions.
> 
> Sahara -- Mike McCune, we should chat about the plans. Are you okay with
> moving towards the common framework and editing the current RST files to
> use the rest_method and rest_parameters Sphinx directives?
> 
> Ceilometer -- sorry, Julien, I hadn't reached out individually to you.
> Could you let me know your plans for the RST API reference docs?
> 
> 
> >   c)When is the table's status changed to "Done"?
> >  nova (compute) and ironic (baremetal) seems first patch merged
> >  and see the document already.
> >
> 
> I'll change those two to Done.
> 
> Thanks for asking -
> Anne
> 
> 
> >
> >
> >   Ref.
> > [1]
> > https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
> >
> >
> > Thanks
> >
> > Atsushi SAKAI
> >
> 
> 
> 
> -- 
> Anne Gentle
> www.justwriteclick.com


-- 
Atsushi SAKAI <sak...@jp.fujitsu.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

[Yahoo-eng-team] [Bug 1571628] Re: os-server-groups description is missing

[Atsushi SAKAI]

** Project changed: openstack-api-site => nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1571628

Title:
  os-server-groups description is missing

Status in OpenStack Compute (nova):
  New

Bug description:
  Description of os-server-groups is missing from the Compute API
  reference [1].

  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1571628/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1572013] Re: missing parameter explaination in "Servers" section of v2.1 compute api

[Atsushi SAKAI]

** Project changed: openstack-api-site => nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1572013

Title:
  missing parameter explaination in "Servers" section of v2.1 compute
  api

Status in OpenStack Compute (nova):
  New

Bug description:
  URL:  http://developer.openstack.org/api-ref-compute-v2.1.html
  I think the request parameters listed in "GET /v2.1/​{tenant_id}​/servers" of 
"Servers" section are not complete, when i want to get all servers of all 
tenants, there should be "?all_tenants=true" in the url, as i read in 
python-novaclient source code and it works actually after testing; but there is 
no specific description about "all_tenant" listed in "Request parameters" 
following in the api documentation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1572013/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1564973] Re: [liberty] add arp_responder flag to linuxbridge agent

[Atsushi SAKAI]

*** This bug is a duplicate of bug 1551805 ***
https://bugs.launchpad.net/bugs/1551805

** This bug has been marked a duplicate of bug 1551805
   add arp_responder flag to linuxbridge agent

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1564973

Title:
  [liberty] add arp_responder flag to linuxbridge agent

Status in neutron:
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/288050
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit c823e8ccb951a4abdf247dd094a794b7741d7cca
  Author: Mark McClain 
  Date:   Wed Feb 10 13:28:21 2016 -0500

  add arp_responder flag to linuxbridge agent
  
  When the ARP responder is enabled, secondary IP addresses explicitly
  allowed by via the allowed-address-pairs extensions do not resolve.
  This change adds the ability to enable the local ARP responder similar
  to the feature in the OVS agent.  This change disables local ARP
  responses by default, so ARP traffic will be sent over the overlay.
  
  DocImpact
  UpgradeImpact
  
  Change-Id: I5da4afa44fc94032880ea59ec574df504470fb4a
  Closes-Bug: 1445089
  (cherry picked from commit bbd881f3a970143e1954cb277e523526c5d0)
  Signed-off-by: Kevin Carter 

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1564973/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1552056] Re: "router-interface-delete port=xxx" deletes the whole port instead of just removing the interface

[Atsushi SAKAI]

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** Changed in: openstack-api-site
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1552056

Title:
  "router-interface-delete port=xxx" deletes the whole port instead of
  just removing the interface

Status in neutron:
  In Progress
Status in openstack-api-site:
  Confirmed

Bug description:
  The help message of "neutron router-interface-delete" says

  "Remove an internal network interface from a router."

  =
  Expected behavior
  =
  neutron router-interface-add subnet=subnetx
  --> creates a port, and adds this port as interface to the router

  neutron router-interface-delete subnet=subnetx
  --> removes that interface from the router and deletes the corresponding port

  
  neutron router-interface-add port=portx
  --> adds an already existing port as interface to the router

  neutron router-interface-delete port=portx
  --> removes that interface from the router. Does NOT delete that 
corresponding port

  =
  Actual result
  =

  "neutron router-interface-delete subnet=subnetx" works as expected.

  BUT

  "neutron router-interface-delete port=portx" does not only remove the
  interface from the router, it also deletes the whole port!

  
  =
  Proposed solution
  =

  Either
  #1 Extend the API description to refelct this behavior

  
  Or
  #2 Change the behavior in the special case to NOT delete the port, but only 
remove the interface from the router

  
  ==
  Steps to reproduce
  ==

  # neutron router-interface-delete -h
  usage: neutron router-interface-delete [-h] [--request-format {json}]
 ROUTER INTERFACE

  Remove an internal network interface from a router.

  positional arguments:
ROUTERID or name of the router.
INTERFACE The format is "SUBNET|subnet=SUBNET|port=PORT". Either
  a subnet or port must be specified. Both ID and name
  are accepted as SUBNET or PORT. Note that "subnet="
  can be omitted when specifying a subnet.


  [root@tecs218 ~(keystone_admin)]# neutron router-create test
  Created a new router:
  +---+--+
  | Field | Value|
  +---+--+
  | admin_state_up| True |
  | external_gateway_info |  |
  | id| 4039bd93-b183-4250-af0f-e9739ac1a19a |
  | name  | test |
  | status| ACTIVE   |
  | tenant_id | 0d76aad1dda94f83a2a0a55c04547434 |
  +---+--+
  [root@tecs218 ~(keystone_admin)]# neutron router-interface-add test  
port=90e0abe1-852b-4cfe-afd9-2bd31a42c279
  Added interface 90e0abe1-852b-4cfe-afd9-2bd31a42c279 to router test.
  [root@tecs218 ~(keystone_admin)]# neutron router-interface-add test  
port=90e0abe1-852b-4cfe-afd9-2bd31a42c27^C
  [root@tecs218 ~(keystone_admin)]# neutron port-show 
90e0abe1-852b-4cfe-afd9-2bd31a42c279
  
+-+---+
  | Field   | Value 
|
  
+-+---+
  | admin_state_up  | True  
|
  | bandwidth   | 0 
|
  | binding:host_id |   
|
  | binding:profile | {}
|
  | binding:vif_details | {}
|
  | binding:vif_type| unbound   
|
  | binding:vnic_type   | normal
|
  | bond| 0 
|
  | cbs | 0 
|
  | device_id   | 4039bd93-b183-4250-af0f-e9739ac1a19a  
|
  | device_owner| 

Re: [Openstack-doc-core] Core Team Review - March 2016

[Atsushi SAKAI]

Lana

 Additionally, I found.
 Following Karma seems high for Matt and me.

> > >>>>>> Current cores not appearing in any stats:

https://launchpad.net/openstack-manuals/+topcontributors
https://launchpad.net/openstack-api-site/+topcontributors

Hopefully, launchpad karma affects the stats :-)

Thanks
Atsushi SAKAI


On Fri, 4 Mar 2016 14:20:54 +0900
Atsushi SAKAI <sak...@jp.fujitsu.com> wrote:

> Lana
> 
> Thank you for commenting me.
> 
> > I use the russelbryant stats 
> > http://stackalytics.com/report/contribution/documentation-group/90
> > I haven't heard anything specific from Atsushi-san.
> 
> I am doing launchpad bugs reviewing mainly (api-site and manuals)
>   (but I recognize working contribution is low at this moment.)
> 
> for example (commenting bug list, not confirmed bug list)
>  https://bugs.launchpad.net/~sakaia/+commentedbugs?orderby=-id=0
> 
> Thanks
> Atsushi SAKAI
> 
> 
> 
> On Fri, 4 Mar 2016 08:39:37 +1000
> Lana Brindley <openst...@lanabrindley.com> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > I use the russelbryant stats (which are linked in the headers), because of 
> > comments made on this list back when we changed the process. The main 
> > reason, IIRC, was because it was more specific to openstack-manuals. Happy 
> > to reopen that conversation, though. In my core reviews, when I use the 
> > term "not appearing in any stats", I mean not appearing on my spreadsheet 
> > (which only looks at the top 12 in each c ategory). I can change the 
> > wording of this to make it clearer. 
> > 
> > I note that, while Matt is still participating at a high level, he just 
> > isn't in the top 12. I put this down to increased focus on the Install 
> > Guide testing, but I'm happy to hear from Matt if I've made an erroneous 
> > assumption there. To respond to Andreas' query about other underperforming 
> > cores, I can explain that Christian and Darren are both focussed on other 
> > interest areas right now, and forewarned me that their contributions would 
> > drop. They will both be returning to normal shortly. I haven't heard 
> > anything specific from Atsushi-san.
> > 
> > Hope that helps,
> > Lana
> > 
> > On 04/03/16 00:37, Anne Gentle wrote:
> > > On Thu, Mar 3, 2016 at 8:16 AM, Mariia Zlatkova <mzlatk...@mirantis.com>
> > > wrote:
> > > 
> > >> I thought we were using this link:
> > >> http://stackalytics.com/report/contribution/documentation-group/90
> > >>
> > >>
> > > To root cause this misperception, I want to point out that I clicked the
> > > links in the column headers. Lana, can you fix those? Whether we point to
> > > stackalytics or russelbryant may also be a point to discuss.
> > > 
> > > Anne
> > > 
> > > 
> > >> Maria
> > >>
> > >> On Thu, Mar 3, 2016 at 3:58 PM, Steve Gordon <sgor...@redhat.com> wrote:
> > >>
> > >>> - Original Message -
> > >>>> From: "Anne Gentle" <annegen...@justwriteclick.com>
> > >>>> To: "Andreas Jaeger" <a...@suse.com>
> > >>>>
> > >>>> On Thu, Mar 3, 2016 at 6:56 AM, Andreas Jaeger <a...@suse.com> wrote:
> > >>>>
> > >>>>> On 2016-03-03 01:19, Lana Brindley wrote:
> > >>>>>> Hi core team,
> > >>>>>>
> > >>>>>> Here's the core reviewer stats for this month[1]:
> > >>>>>>
> > >>>>>> Current cores not appearing in any stats:
> > >>>>>> Matthew Kassawara
> > >>>>>>
> > >>>>>> Matt has been working hard on Install Guide testing (which doesn’t
> > >>> run
> > >>>>>> through Gerrit), so this is expected. It’s also expected to impact
> > >>> the
> > >>>>>> stats of other core reviewers involved in that task.
> > >>>>>>
> > >>>>>
> > >>>>> What does "not appearing in any stats" mean exactly?
> > >>>>>
> > >>>>>
> > >>>> I couldn't find him on Stackalytics, take a look at this (which makes 
> > >>>> me
> > >>>> wonder if the affiliation change is broken?)
> > >>>>
> > >>>>
> > >>> http://stackalytics.com/?module=

Re: [Openstack-doc-core] Core Team Review - March 2016

[Atsushi SAKAI]

Lana

Thank you for commenting me.

> I use the russelbryant stats 
> http://stackalytics.com/report/contribution/documentation-group/90
> I haven't heard anything specific from Atsushi-san.

I am doing launchpad bugs reviewing mainly (api-site and manuals)
  (but I recognize working contribution is low at this moment.)

for example (commenting bug list, not confirmed bug list)
 https://bugs.launchpad.net/~sakaia/+commentedbugs?orderby=-id=0

Thanks
Atsushi SAKAI



On Fri, 4 Mar 2016 08:39:37 +1000
Lana Brindley <openst...@lanabrindley.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I use the russelbryant stats (which are linked in the headers), because of 
> comments made on this list back when we changed the process. The main reason, 
> IIRC, was because it was more specific to openstack-manuals. Happy to reopen 
> that conversation, though. In my core reviews, when I use the term "not 
> appearing in any stats", I mean not appearing on my spreadsheet (which only 
> looks at the top 12 in each c ategory). I can change the wording of this to 
> make it clearer. 
> 
> I note that, while Matt is still participating at a high level, he just isn't 
> in the top 12. I put this down to increased focus on the Install Guide 
> testing, but I'm happy to hear from Matt if I've made an erroneous assumption 
> there. To respond to Andreas' query about other underperforming cores, I can 
> explain that Christian and Darren are both focussed on other interest areas 
> right now, and forewarned me that their contributions would drop. They will 
> both be returning to normal shortly. I haven't heard anything specific from 
> Atsushi-san.
> 
> Hope that helps,
> Lana
> 
> On 04/03/16 00:37, Anne Gentle wrote:
> > On Thu, Mar 3, 2016 at 8:16 AM, Mariia Zlatkova <mzlatk...@mirantis.com>
> > wrote:
> > 
> >> I thought we were using this link:
> >> http://stackalytics.com/report/contribution/documentation-group/90
> >>
> >>
> > To root cause this misperception, I want to point out that I clicked the
> > links in the column headers. Lana, can you fix those? Whether we point to
> > stackalytics or russelbryant may also be a point to discuss.
> > 
> > Anne
> > 
> > 
> >> Maria
> >>
> >> On Thu, Mar 3, 2016 at 3:58 PM, Steve Gordon <sgor...@redhat.com> wrote:
> >>
> >>> - Original Message -
> >>>> From: "Anne Gentle" <annegen...@justwriteclick.com>
> >>>> To: "Andreas Jaeger" <a...@suse.com>
> >>>>
> >>>> On Thu, Mar 3, 2016 at 6:56 AM, Andreas Jaeger <a...@suse.com> wrote:
> >>>>
> >>>>> On 2016-03-03 01:19, Lana Brindley wrote:
> >>>>>> Hi core team,
> >>>>>>
> >>>>>> Here's the core reviewer stats for this month[1]:
> >>>>>>
> >>>>>> Current cores not appearing in any stats:
> >>>>>> Matthew Kassawara
> >>>>>>
> >>>>>> Matt has been working hard on Install Guide testing (which doesn’t
> >>> run
> >>>>>> through Gerrit), so this is expected. It’s also expected to impact
> >>> the
> >>>>>> stats of other core reviewers involved in that task.
> >>>>>>
> >>>>>
> >>>>> What does "not appearing in any stats" mean exactly?
> >>>>>
> >>>>>
> >>>> I couldn't find him on Stackalytics, take a look at this (which makes me
> >>>> wonder if the affiliation change is broken?)
> >>>>
> >>>>
> >>> http://stackalytics.com/?module=openstack-manuals=liberty=commits_id=ionosphere80
> >>>
> >>> That query is explicitly pinned to liberty only and also measuring
> >>> commits not reviews. I would think these are the more relevant 
> >>> stackalytics
> >>> views (and Matt is on them):
> >>>
> >>> http://stackalytics.com/report/contribution/openstack-manuals/30
> >>> http://stackalytics.com/report/contribution/openstack-manuals/90
> >>>
> >>> I still tend to use Russell's stats at:
> >>>
> >>> http://russellbryant.net/openstack-stats/docs-reviewers-30.txt
> >>> http://russellbryant.net/openstack-stats/docs-reviewers-60.txt
> >>> http://russellbryant.net/openstack-stats/docs-reviewers-90.txt
> >>>
> >>> -Steve
> >>>
> >&

[Yahoo-eng-team] [Bug 1548511] Re: Shared pools support

[Atsushi SAKAI]

** Project changed: openstack-manuals => openstack-api-site

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1548511

Title:
  Shared pools support

Status in neutron:
  Confirmed
Status in openstack-api-site:
  New

Bug description:
  https://review.openstack.org/218560
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 4f3cf154829fcd69ecf3fa7f4e49f82d0104a4f0
  Author: Stephen Balukoff 
  Date:   Sat Aug 29 02:51:09 2015 -0700

  Shared pools support
  
  In preparation for L7 switching functionality, we need to
  reduce the rigidity of our model somewhat and allow pools
  to exist independent of listeners and be shared by 0 or
  more listeners. With this patch, pools are now associated
  with loadbalancers directly, and there is now a N:M
  relationship between listeners and pools.
  
  This patch does alter the Neutron LBaaS v2 API slightly,
  but all these changes are backward compatible. Nevertheless,
  since Neutron core dev team has asked that any API changes
  take place in an extension, that is what is being done in
  this patch.
  
  This patch also updates the reference namespace driver to
  render haproxy config templates correctly given the pool
  sharing functionality added with the patch.
  
  Finally, the nature of shared pools means that the usual
  workflow for tenants can be (but doesn't have to be)
  altered such that pools can be created before listeners
  independently, and assigned to listeners as a later step.
  
  DocImpact
  APIImpact
  Partially-Implements: blueprint lbaas-l7-rules
  Change-Id: Ia0974b01f1f02771dda545c4cfb5ff428a9327b4

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1548511/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1527719] Re: Adding a VNIC type for physical functions

[Atsushi SAKAI]

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** Changed in: openstack-api-site
 Assignee: (unassigned) => Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1527719

Title:
  Adding a VNIC type for physical functions

Status in neutron:
  Fix Released
Status in openstack-api-site:
  New
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/246923
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 2c60278992d5a21724105ed0ca6e1d2f3e5c
  Author: Brent Eagles <beag...@redhat.com>
  Date:   Mon Nov 9 09:26:53 2015 -0330

  Adding a VNIC type for physical functions
  
  This change adds a new VNIC type to distinguish between virtual and
  physical functions in SR-IOV.
  
  The new VNIC type 'direct-physical' deviates from the behavior of
  'direct' VNICs for virtual functions. While neutron tracks the resource
  as a port, it does not currently perform any management functions.
  Future changes may extend the segment mapping functionality that is
  currently based on agent configuration to include direct types.
  However, the direct-physical VNICs will not have functional parity with
  the other SR-IOV VNIC types in that quality of service and port security
  functionality is not available.
  
  APIImpact
  DocImpact: Add description for new 'direct-physical' VNIC type.
  
  Closes-Bug: #1500993
  
  Change-Id: If1ab969c2002c649a3d51635ca2765c262e2d37f

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1527719/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1527235] [NEW] [doc] glanceapi.rst missing ova

[Atsushi SAKAI]

Public bug reported:

glanceapi.rst missing ova for x-image-meta-container_format

** Affects: glance
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: In Progress

** Changed in: glance
 Assignee: (unassigned) => Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1527235

Title:
  [doc] glanceapi.rst missing ova

Status in Glance:
  In Progress

Bug description:
  glanceapi.rst missing ova for x-image-meta-container_format

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1527235/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1517212] Re: Support new v2 API image filters

[Atsushi SAKAI]

** Also affects: glance
   Importance: Undecided
   Status: New

** Changed in: glance
 Assignee: (unassigned) => Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1517212

Title:
  Support new v2 API image filters

Status in Glance:
  New
Status in openstack-api-site:
  Confirmed

Bug description:
  https://review.openstack.org/197388
  commit a4c6f126362e5dd43b1c99faeffeb46af389fe4a
  Author: Steve Lewis <steve...@gmail.com>
  Date:   Tue Jun 30 11:16:01 2015 -0700

  Support new v2 API image filters
  
  Provide support in Glance API for querying the image list for
  created_at and updated_at times using guidance from the API Working
  Group recommendations for filtering. Filtering is applied at the DB
  layer.
  
  DocImpact
  ApiImpact
  MitakaPriority
  Change-Id: Ie94295bb82779ec17ab773928c71ae4a9ee8fbcc
  Implements bp: v2-additional-filtering

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1517212/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1524006] Re: NotImplementedError raised while create network using Nova REST API

[Atsushi SAKAI]

Would you ask your questions in following URL?
https://ask.openstack.org/en/questions/


** Changed in: openstack-api-site
   Status: New => Invalid

** Changed in: nova
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1524006

Title:
  NotImplementedError raised while create network using Nova REST API

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-api-site:
  Invalid

Bug description:
  Hi,

  I've stucked with error:
  {"computeFault":
  {"message": "Unexpected API Error. Please report this at
  http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n
  ", "code": 500}}

  It happened when I try create network for non-admin project using Nova REST 
API
  Source: http://developer.openstack.org/api-ref-compute-v2.1.html

  POST
  http://10.1.244.10:8774/v2.1/090aee2684a04e8397193a118a6e91b0/os-networks

  POST data:
  {
  "network": {
  "label": "scale-1-net",
  "cidr": "172.1.0.0/24",
  "mtu": 9000,
  "dhcp_server": "172.1.0.2",
  "enable_dhcp": false,
  "share_address": true,
  "allowed_start": "172.1.0.10",
  "allowed_end": "172.1.0.200"
  }
  }

  What's wrong?
  or
  What's the solution?

  Thanks a lot.
  ---
  Release: 2.1.0 on 2015-12-08 06:12
  SHA: 60c5c2798004984738d171055dbc2a6fd37a85fe
  Source: 
http://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/index.rst
  URL: http://developer.openstack.org/api-guide/compute/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524006/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1515445] [NEW] / and /versions have same reply with another response

[Atsushi SAKAI]

Public bug reported:

If this is wrong asking in here, it would be appreciated to notice me
the right place (ML etc).

GET / and /versions have same reply with another response 
one is 300, another is 200.
Is there any reason?

P.S.
I am checking the / and /versions API for API-Ref and found this issue.

Ref
https://review.openstack.org/#/c/244063/

** Affects: glance
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1515445

Title:
  / and /versions have same reply with another response

Status in Glance:
  New

Bug description:
  If this is wrong asking in here, it would be appreciated to notice me
  the right place (ML etc).

  GET / and /versions have same reply with another response 
  one is 300, another is 200.
  Is there any reason?

  P.S.
  I am checking the / and /versions API for API-Ref and found this issue.

  Ref
  https://review.openstack.org/#/c/244063/

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1515445/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1514792] [NEW] needs developer document update for with_venv.sh (oslo.incubator) deletion

[Atsushi SAKAI]

Public bug reported:

needs  document update for with_venv.sh (oslo.incubator) deletion.

effecting files are

keystone/doc/source/developing.rst
keystone/doc/source/devref/development.environment.rst

This is related to following patch.
https://github.com/openstack/keystone/commit/693755ee255ff7ba9c00f3f3cc86d75e90ad0b3a

** Affects: keystone
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1514792

Title:
  needs developer document update for with_venv.sh (oslo.incubator)
  deletion

Status in OpenStack Identity (keystone):
  New

Bug description:
  needs  document update for with_venv.sh (oslo.incubator) deletion.

  effecting files are

  keystone/doc/source/developing.rst
  keystone/doc/source/devref/development.environment.rst

  This is related to following patch.
  
https://github.com/openstack/keystone/commit/693755ee255ff7ba9c00f3f3cc86d75e90ad0b3a

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1514792/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1483993] [NEW] Fix three typos on nova/pci directory

[Atsushi SAKAI]

Public bug reported:

Fix three typos on nova/pci directory

QuicAssist= QuickAssist
comptue = compute
trackes=tracks

I am looking following report and found it.
https://bugs.launchpad.net/openstack-manuals/+bug/1381017

** Affects: nova
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1483993

Title:
  Fix three typos on nova/pci directory

Status in OpenStack Compute (nova):
  New

Bug description:
  Fix three typos on nova/pci directory

  QuicAssist= QuickAssist
  comptue = compute
  trackes=tracks

  I am looking following report and found it.
  https://bugs.launchpad.net/openstack-manuals/+bug/1381017

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1483993/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1477898] [NEW] Fix five typos on keystone document

[Atsushi SAKAI]

Public bug reported:

Fix four typos and Add one space on keystone document

encryted   = encrypted
counterintuitive = counter intuitive (space added)
infomration =information
configuraton   = configuration
   http://docs.openstack.org/developer/keystone/configuration.html

Organizaion = Organization
   http://docs.openstack.org/developer/keystone/configure_federation.html

$ git diff | diffstat
 configuration.rst|8 
 configure_federation.rst |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

** Affects: keystone
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1477898

Title:
  Fix five typos on keystone document

Status in Keystone:
  In Progress

Bug description:
  Fix four typos and Add one space on keystone document

  encryted   = encrypted
  counterintuitive = counter intuitive (space added)
  infomration =information
  configuraton   = configuration
 http://docs.openstack.org/developer/keystone/configuration.html

  Organizaion = Organization
 http://docs.openstack.org/developer/keystone/configure_federation.html

  $ git diff | diffstat
   configuration.rst|8 
   configure_federation.rst |2 +-
   2 files changed, 5 insertions(+), 5 deletions(-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1477898/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1478003] [NEW] Fix seven typos on nova documentation

[Atsushi SAKAI]

Public bug reported:

Fix seven typos on nova documentation

behaviour = behavior4
poicy   =  policy
schedular  =  scheduler
environement = environment

** Affects: nova
 Importance: Undecided
 Assignee: Atsushi SAKAI (sakaia)
 Status: In Progress

** Changed in: nova
 Assignee: (unassigned) = Atsushi SAKAI (sakaia)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1478003

Title:
  Fix seven typos on nova documentation

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Fix seven typos on nova documentation

  behaviour = behavior4
  poicy   =  policy
  schedular  =  scheduler
  environement = environment

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1478003/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[jruby-dev] Which versioning method is taken on JRuby?

[Atsushi SAKAI]

Hello.I am newbies on this mailing list.

I have a question about JRuby versioning method.
Which versioning method is taken on JRuby?
In my understanding, method 2) is current versiong method on JRuby.

1)As you know, Linux and Xen has a versioning like w.x.y.z or x.y.z
and .z means stable version. 
So x.y and .z meaning is different in these packages.
In these packages, stable tree and unstable tree maintained 
with parallel

2)And for libvirt, versioning method is different.
the versioning is composed of x.y.z. and .z means minor version up
and x.y means major version up.
In this package, code tree is maintained as one tree,
not two or more.

Thanks
Atsushi SAKAI

-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [libvirt] Switch from CVS to GIT is done

[Atsushi SAKAI]

Hi, Daniel

I am happy to hear this, since I am primaly tracking libvirt via git.

From seeing http://libvirt.org/git/,
only 4 packages are controlled under git.
(libvirt, libvirt-glib, libvirt-perl, libvirt-tck)
Will other libvirt related tools goes to the directory in future?

Thanks
Atsushi SAKAI



Daniel Veillard veill...@redhat.com wrote:

 
   Thanks to Jim Meyering we now have a new git repository, I deprecated the
 CVS repository, it's read only, you should still be able to keep it
 around to make patches for a few weeks if needed.
   The new repo is at:
 http://libvirt.org/git/?p=libvirt.git;a=summary
 
 Unfortunately Jim had to clean up the conversion from CVS that was
 used previously at git://git.et.redhat.com/libvirt.git so the two
 are not compatible and the best is to clone a new tree using
 
git clone git://libvirt.org/libvirt.git
 
 and then copying over your set of patches with git format-patch in the
 old dir and git am to paste them into the new cloned-dir (Jim can
 certainly provide more details if needed).
 
   Let us know if you see something weird in the new tree or on the web
 site, I have updated the download informations at
http://libvirt.org/downloads.html
 
 A few things may change but I guess the switch is done at this point,
 
   Many thanks to Jim for maintaining the old tree and the migration !
 
 Daniel
 
 -- 
 Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
 dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
 http://veillard.com/ | virtualization library  http://libvirt.org/
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re:

[Atsushi SAKAI]

You should send to majord...@vger.kernel.org
not kvm@vger.kernel.org

see below

Thanks
Atsushi SAKAI

Josh Borke joshbo...@gmail.com wrote:

 subscribe kvm
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[et-mgmt-tools] Question about virt-viewer connection when guest reboots

[Atsushi SAKAI]

Hi,

  I have a question about virt-viewer connection when guest reboots.
As you know, when guest reboots, virt-viewer destroyed.

Is there any way to keep virt-viewer running over guest reboots?

Thanks
Atsushi SAKAI




___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[libvirt] Question about libvirt-qpid

[Atsushi SAKAI]

2 questions.


1)Would you explain the use case for libvirt-qpid?
  Which case AMDQ messaging is good for.
  If I am missing some document, Please point me.
  By the way I am reading through following document.
  
http://jira.amqp.org/confluence/download/attachments/2523279/amqp-model-draft101.pdf
  I guess this is fit for huge data case?


2)Where is the document about set up libvirt-qpid?
There is not in package document.
Only in mailing list, it should goes some document.
https://www.redhat.com/archives/libvir-list/2008-September/msg00388.html

Thanks
Atsushi SAKAI



--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] about libvirt-qpid on libvirt.org

[Atsushi SAKAI]

Hi, Daniel

  It looks good for me.

Thanks
Atsushi SAKAI


Daniel P. Berrange berra...@redhat.com wrote:

 On Tue, Jan 27, 2009 at 12:51:57PM +0900, Atsushi SAKAI wrote:
  Hi,
  
I have a question about libvirt-qpid.
  The libvirt-qpid is working for QPID broker?
  If so, it should be added in livirt is section of following pages.
  http://libvirt.org/
  How do you think?
 
 
 Yes, it should be listed - here is an updated front page, also added
 the User Mode Linux driver, and mentioning the Windows client support.
 I also added details of URI format to all the per-driver pages, since
 people often seem to ask about this
 
 
 Daniel
 
 diff -r f787e41fb699 docs/drvopenvz.html
 --- a/docs/drvopenvz.html Tue Jan 27 11:15:48 2009 +
 +++ b/docs/drvopenvz.html Tue Jan 27 11:39:31 2009 +
 @@ -142,6 +142,7 @@
  /p
  pre
  openvz:///system (local access)
 +openvz+unix:///system(local access)
  openvz://example.com/system  (remote access, TLS/x509)
  openvz+tcp://example.com/system  (remote access, SASl/Kerberos)
  openvz+ssh://r...@example.com/system (remote access, SSH tunnelled)
 diff -r f787e41fb699 docs/drvopenvz.html.in
 --- a/docs/drvopenvz.html.in  Tue Jan 27 11:15:48 2009 +
 +++ b/docs/drvopenvz.html.in  Tue Jan 27 11:39:31 2009 +
 @@ -21,6 +21,7 @@
  
  pre
  openvz:///system (local access)
 +openvz+unix:///system(local access)
  openvz://example.com/system  (remote access, TLS/x509)
  openvz+tcp://example.com/system  (remote access, SASl/Kerberos)
  openvz+ssh://r...@example.com/system (remote access, SSH tunnelled)
 diff -r f787e41fb699 docs/drvqemu.html
 --- a/docs/drvqemu.html   Tue Jan 27 11:15:48 2009 +
 +++ b/docs/drvqemu.html   Tue Jan 27 11:39:31 2009 +
 @@ -149,6 +149,23 @@
   node. If both are found, then Xen paravirtualized guests can be run 
 using
   the KVM hardware acceleration.
/li/ul
 +h2Connections to QEMU driver/h2
 +p
 +The libvirt QEMU driver is a multi-instance driver, providing a single
 +system wide privileged driver (the system instance), and per-user
 +unprivileged drivers (the session instance). The of the driver protocol
 +is qemu. Some example conection URIs for the libvirt driver are:
 +/p
 +pre
 +qemu:///session  (local access to per-user instance)
 +qemu+unix:///session (local access to per-user instance)
 +
 +qemu:///system   (local access to system instance)
 +qemu+unix:///system  (local access to system instance)
 +qemu://example.com/system(remote access, TLS/x509)
 +qemu+tcp://example.com/system(remote access, SASl/Kerberos)
 +qemu+ssh://r...@example.com/system   (remote access, SSH tunnelled)
 +/pre
  h2
a name=xmlconfig id=xmlconfigExample domain XML config/a
  /h2
 diff -r f787e41fb699 docs/drvqemu.html.in
 --- a/docs/drvqemu.html.inTue Jan 27 11:15:48 2009 +
 +++ b/docs/drvqemu.html.inTue Jan 27 11:39:31 2009 +
 @@ -32,6 +32,26 @@
/li
  /ul
  
 +h2Connections to QEMU driver/h2
 +
 +p
 +The libvirt QEMU driver is a multi-instance driver, providing a single
 +system wide privileged driver (the system instance), and per-user
 +unprivileged drivers (the session instance). The of the driver protocol
 +is qemu. Some example conection URIs for the libvirt driver are:
 +/p
 +
 +pre
 +qemu:///session  (local access to per-user instance)
 +qemu+unix:///session (local access to per-user instance)
 +
 +qemu:///system   (local access to system instance)
 +qemu+unix:///system  (local access to system instance)
 +qemu://example.com/system(remote access, TLS/x509)
 +qemu+tcp://example.com/system(remote access, SASl/Kerberos)
 +qemu+ssh://r...@example.com/system   (remote access, SSH tunnelled)
 +/pre
 +
  h2a name=xmlconfigExample domain XML config/a/h2
  
  h3QEMU emulated guest on x86_64/h3
 diff -r f787e41fb699 docs/drvtest.html
 --- a/docs/drvtest.html   Tue Jan 27 11:15:48 2009 +
 +++ b/docs/drvtest.html   Tue Jan 27 11:39:31 2009 +
 @@ -126,6 +126,22 @@
/div
div id=content
  h1Test mock driver/h1
 +h2Connections to Test driver/h2
 +p
 +The libvirt Test driver is a per-process fake hypervisor driver,
 +with a driver name of 'test'. The driver maintains all its state
 +in memory. It can start with a pre-configured default config, or
 +be given a path to a alternate config. Some example conection URIs
 +for the libvirt driver are:
 +/p
 +pre
 +test:///default (local access

[libvirt] about libvirt-qpid on libvirt.org

[Atsushi SAKAI]

Hi,

  I have a question about libvirt-qpid.
The libvirt-qpid is working for QPID broker?
If so, it should be added in livirt is section of following pages.
http://libvirt.org/
How do you think?
(If agreed, I add it.)

Thanks
Atsushi SAKAI


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[Lguest] [PATCH] typos fix

[Atsushi SAKAI]

3 points

lguest_asm.S = i386_head.S
LHCALL_BREAK = LHREQ_BREAK
perferred= preferred

Signed-off-by: Atsushi SAKAI sak...@jp.fujitsu.com


 arch/x86/lguest/boot.c |4 ++--
 drivers/lguest/core.c  |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index a7ed208..92f1c6f 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -931,7 +931,7 @@ static void lguest_restart(char *reason)
  * that we can fit comfortably.
  *
  * First we need assembly templates of each of the patchable Guest operations,
- * and these are in lguest_asm.S. */
+ * and these are in i386_head.S. */
 
 /*G:060 We construct a table from the assembler templates: */
 static const struct lguest_insns
@@ -1093,7 +1093,7 @@ __init void lguest_init(void)
acpi_ht = 0;
 #endif
 
-   /* We set the perferred console to hvc.  This is the hypervisor
+   /* We set the preferred console to hvc.  This is the hypervisor
 * virtual console driver written by the PowerPC people, which we also
 * adapted for lguest's use. */
add_preferred_console(hvc, 0, NULL);
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 90663e0..60156df 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -224,7 +224,7 @@ int run_guest(struct lg_cpu *cpu, unsigned long __user 
*user)
break;
 
/* If the Guest asked to be stopped, we sleep.  The Guest's
-* clock timer or LHCALL_BREAK from the Waker will wake us. */
+* clock timer or LHREQ_BREAK from the Waker will wake us. */
if (cpu-halted) {
set_current_state(TASK_INTERRUPTIBLE);
schedule();




___
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest

Re: [libvirt] Fine grained Access Control in libVirt

[Atsushi SAKAI]

Hi, Dan

Would you explain the difference with sVirt?
The final goal sVirt seems same form me.
(for example, define many security domain etc in .te file.)

Or it just a little changes from sVirt implementation?

Thanks
Atsushi SAKAI


Daniel P. Berrange berra...@redhat.com wrote:

 On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote:
  After some background research it doesn't look like anyone have taken on 
  the task yet to add fine-grained access control to libVirt (only option 
  right now is R/W or RO mode).
  
  Desired is an addition to libVirt that enables access control on 
  individual actions and data that can be accessed through the library API.
  This could take the form of an AC-module that, based on the identity of 
  the caller, checks each call and grants/denies access to carry out the 
  action (could also take parameters in account) and optionally filter the 
  return data.
  The AC-module could then interface different backend AC solutions 
  (SELinux, RBAC, ...) or alternatively implement an internal scheme.
  
  When looking at the libvirt core and driver framework it seems promising 
  to inject these kind of call-out hooks either in libvirt.c or between 
  libvirt.c and the underlying drivers, by doing this AC will be enforced 
  independent of if a local or remote call is done to libVirt.
  
  I propose an approach to create an AC-module that conforms to the driver 
  API in libVirt and to inject it in the call-path between libvirt.c and the 
  driver(s) to enable the AC-module to inspect the call before sending it to 
  the real driver.
  Normal call path: user - libvirt.c - driver_x
  AC-module injected in call path: user - libvirt.c - AC-module - 
  driver_x
  
  By doing this it can be loaded/unloaded in run-time and also selectable 
  what driver paths it should enforce (hypervisor(aka. driver), storage, 
  network...).
  The AC-module can also be made in different flavors for different AC 
  backend (SELinux, RBAC, internal, ...) solutions and the appropriate 
  AC-module could be loaded without needing re-compiling.
  This approach would also leave a very small footprint in existing libvirt 
  code (only need to inject AC-module driver after normal drivers has been 
  loaded)
 
 FYI, I had discussed the alternative approach with Konrad offlist
 prior to this thread. Namely, instead of having a driver, layered
 in, put a call to something like virCheckAccess() directly into
 libvirt.c replacing the RO checks. The complication with doing it
 this way, is deciding what information to pass to the virCheckAccess
 methods. Obviously the operation name, and then some context for
 the object to the be checked. Do we just pass the virDomainPtr
 in there. Might need the XML for a new domain create call. Might
 want the other virConnectPtr for a migrate call and so on. Seems
 like we'd quickly end up having to pass all possible params through
 to the virCheckAcces method. At which point it really just becomes
 simpler to layer in the checks via the driver API which already
 has access to all the neccessary bits of info.
 
 So I think its reasonable to have MAC calls stacked into the driver
 API as Konrad illustrates above. The initial impl would just duplicate
 our existing RO checks, then we can consider other impls RBAC/SELinux
 etc
 
 Daniel
 -- 
 |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
 |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
 |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] RE: Libvirt - Xen Enterprise - Koan

[Atsushi SAKAI]

Hello,

  Just one question.
  How about using XenAPI for XenEnterprise?
I am not familiar with XenEnterprise.
But It should have some API for a developer.

Thanks
Atsushi SAKAI


Daniel Veillard veill...@redhat.com wrote:

 On Tue, Jan 06, 2009 at 12:08:14PM -, gerhardus.geldenh...@gta-travel.com 
 wrote:
  Damm, 
  Well at least a conclusive answer. I am assuming it would be relatively
  big undertaking to write a new driver?
 
   No idea, look at other drivers, some are simple enough, others are
 more complex. But basically since it's not open-source the amount
 of interested people will shink, there is also the problem of connecting
 libvirt and the XenE management depending on the Licencing terms of
 their own stack. It's not game over, but it sounds like restarting from
 scratch...
 
 Daniel
 
 -- 
 Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
 dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
 http://veillard.com/ | virtualization library  http://libvirt.org/
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [Fedora-xen] How To Test Dom0 Xen Support In Fedora 10

[Atsushi SAKAI]

Hello

Dom0 is not supported on Fedora 10.
It should wait until upstream kernel support.
Or you should install upstream-Xen.

For more detail(Fedora status) see below.

https://fedoraproject.org/wiki/Features/XenPvopsDom0
Dom0 status: awaiting upstream kernel support 

Thanks
Atsushi SAKAI








Robert L Cochran cochr...@speakeasy.net wrote:

 Hello,
 
 I'm an experienced IBM mainframe programmer with just a little C and
 Java coding experience. I have no experience in the programming part of
 virtualization. I currently do have CentOS 5.2 running as a guest under
 VMWare workstation (an older version which is about a year old, running
 on a Fedora 7 host. And yes, I know Fedora 7 is long out of date.)
 
 I would like to jump in the water and get my feet wet, though. Can
 someone like me test Dom0 Xen support in Fedora 10? If so, is there a
 web resource somewhere spelling out how to get started with testing? I
 will need the steps involved in patching and building a test kernel
 pointed out to me.
 
 I just bought a new laptop, the Dell Latitude E6400 with the Intel P9500
 processor. I think this processor has virtualization technology (vmx
 extensions?) so the hardware for testing is there.
 
 Thanks
 
 Bob Cochran
 
 
 --
 Fedora-xen mailing list
 Fedora-xen@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-xen


--
Fedora-xen mailing list
Fedora-xen@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-xen

Re: [Fedora-xen] Beginner in Xen

[Atsushi SAKAI]

Hello

May be you know Xen supports up to Fedora 8.
After that, Fedora does not support Xen.(Fedora 9 and 10)
More strictly speaking it supports Hypervisor and DomU only, 
Dom0(Privileged Domain) is not supported.

If you want to run Xen on Fedora,
You should install upstream Xen manually or
 wait until Dom0 paravirt_ops is merged into Linux.


Thanks
Atsushi SAKAI

Rodrigo Menezes [EMAIL PROTECTED] wrote:

 Guys,
 
 My name is Rodrigo Menezes, I'm Fedora Ambassador from Brazil and love 
 virtualization. I never used Xen, always worked with VirtualBox, Vmware 
 and MS Virtual Server. Now I'd like to dedicate my time to work with Xen 
 Server.
 
 My first assign is to create a leacture to present in events in Brazil, 
 but I wanna start from the begining. Can you provide me some important 
 documentation to start studying?
 
 Cheers,
 
 Rodrigo Menezes
 __
 Fa軋 liga鋏es para outros computadores com o novo Yahoo! Messenger 
 http://br.beta.messenger.yahoo.com/ 
 
 --
 Fedora-xen mailing list
 Fedora-xen@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-xen


--
Fedora-xen mailing list
Fedora-xen@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-xen

Re: [libvirt] [PATCH] add the check of memory size in xenXMDriver forsetmem of Xen domain

[Atsushi SAKAI]

Hi, Daniel,

This patch itself is OK.

But I also think MIN_XEN_GUEST_SIZE should be defined in xen_unified.h 
not src/internal.h. Since this variable is Xen specific.
How do you think?

Thanks
Atsushi SAKAI


S.Sakamoto [EMAIL PROTECTED] wrote:

 Hi,
 
 I make the patch.
 This patch adds the check of memory size in xenXMDriver,
 to handle the xenStoreDriver error when the set value
 by setmem(setmaxmem) is 4096-65535 definitely.
 
 
 Thanks,
 Shigeki Sakamoto.
 
 
 Index: src/xm_internal.c
 ===
 RCS file: /data/cvs/libvirt/src/xm_internal.c,v
 retrieving revision 1.95
 diff -u -p -r1.95 xm_internal.c
 --- src/xm_internal.c 24 Oct 2008 11:20:08 -  1.95
 +++ src/xm_internal.c 31 Oct 2008 05:52:27 -
 @@ -1273,6 +1273,8 @@ int xenXMDomainSetMemory(virDomainPtr do
  return (-1);
  if (domain-id != -1)
  return (-1);
 +if (memory  1024 * MIN_XEN_GUEST_SIZE);
 +return (-1);
  
  if (!(filename = virHashLookup(nameConfigMap, domain-name)))
  return (-1);
 
 
 
  At first, libvirt.c should not check VMM-arch specific value.
  In this meaning, xs_internal.c do the right thing.
  The problem is error handling on libvirt.c(Xen Store error is not handled 
  properly).
  Do you investigate it?
  
  Thanks
  Atsushi SAKAI
  
  
  
  S.Sakamoto [EMAIL PROTECTED] wrote:
  
   Hi,
   
   I have a question.
   Why does libvirt check size of memory in xenStoreDomainSetMemory of 
   xs_internal.c?
   
   In the xen not exclude lifecycle,
   when I do the following command for the domain that is shutoff,
   error message is output and return value is 0 and the definition 
   file(=/etc/xen/XXX) is updated.
   
 
 # virsh setmem(or setmaxmem) guestdom 65535(4096-65535)
 libvir: Xen Store error : invalid argument in xenStoreDomainSetMemory
 
 # echo $?
 0
 
   
   As a result that I research this,
   this error message is output by the check of the memory size in 
   xenStoreDriver.
   Because libvirt checks the memory size of under 4096 in libvirt.c,
   I think that libvirt should check memory size range of 4096-65535 in 
   libvirt.c.
   
   
   Thanks,
   Shigeki Sakamoto.
   
   --
   Libvir-list mailing list
   Libvir-list@redhat.com
   https://www.redhat.com/mailman/listinfo/libvir-list
  
  
  
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Q]Why does libvirt check size of memory inxenStoreDriver?

[Atsushi SAKAI]

Hi, Shigeki

At first, libvirt.c should not check VMM-arch specific value.
In this meaning, xs_internal.c do the right thing.
The problem is error handling on libvirt.c(Xen Store error is not handled 
properly).
Do you investigate it?

Thanks
Atsushi SAKAI



S.Sakamoto [EMAIL PROTECTED] wrote:

 Hi,
 
 I have a question.
 Why does libvirt check size of memory in xenStoreDomainSetMemory of 
 xs_internal.c?
 
 In the xen not exclude lifecycle,
 when I do the following command for the domain that is shutoff,
 error message is output and return value is 0 and the definition 
 file(=/etc/xen/XXX) is updated.
 
   
   # virsh setmem(or setmaxmem) guestdom 65535(4096-65535)
   libvir: Xen Store error : invalid argument in xenStoreDomainSetMemory
   
   # echo $?
   0
   
 
 As a result that I research this,
 this error message is output by the check of the memory size in 
 xenStoreDriver.
 Because libvirt checks the memory size of under 4096 in libvirt.c,
 I think that libvirt should check memory size range of 4096-65535 in 
 libvirt.c.
 
 
 Thanks,
 Shigeki Sakamoto.
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC] sVirt v0.10 - initial prototype

[Atsushi SAKAI]

Hi, James

I have a question just for interest.

The security context stores like
/etc/selinux/targeted/contexts/files/file_contexts.

But you are storeing the domain security label on libvirt specific XML.
Of course, this is good for libvirt POV.

Is it permitted for SELinux policy POV?


By the way, I want to see the further discussion of the Requirements.
 Requirements not yet addressed include:

Thanks
Atsushi SAKAI



James Morris [EMAIL PROTECTED] wrote:

[snip]
 The domain security label configuration format is as follows:
 
 # virsh dumpxml sys1
 domain
 
   seclabel model='selinux'
 labelsystem_u:system_r:virtd_t:s0/label
 policytypetargeted/policytype
   /seclabel
 /domain
 
 It's possible to query the security label of a running domain via virsh:
 
 # virsh dominfo sys1
 Id: 1
 Name:   sys1
 UUID:   fa3c8e06-0877-2a08-06fd-f2479b7bacb4
 OS Type:hvm
 State:  running
 CPU(s): 1
 CPU time:   11.4s
 Max memory: 524288 kB
 Used memory:524288 kB
 Autostart:  disable
 Security label: system_u:system_r:virtd_t:s0 (selinux/targeted/enforcing)
 
 The security label is deterimed via the new virDomainGetSecLabel() API 
 method, which is transported over RPC to the backend driver (qemu in this 
 case), and is entirely independent of the local security model, if any.  
 e.g. this command could be run remotely from an entirely different 
 platform: you just see what's happening on the remote system, as with 
 other attributes of the domain.
 
 Feedback on the design thus far is sought before proceeding to more 
 comprehensive integration.
 
 In particular, I'd be interested in any thoughts on the placement of the 
 security labeling driver within libvirt, as this seems to be the most 
 critical architectural issue (I've already refactored this aspect once).  
 
 Currently, the idea is to attach the security labeling driver to the virt 
 driver, rather than implement it independently as a top-level component as 
 in the case of other types of drivers (e.g. storage).  This is because 
 process-based security labeling is highly dependent on the kind of 
 virtualization in use, and may not make sense at all in some cases (e.g. 
 when using a non-Linux hypervisor, or containers).
 
 In the case of qemu, a security labeling driver is added to qemud:
 
 @@ -63,6 +64,7 @@ struct qemud_driver {
  char *vncListen;
  
  virCapsPtr caps;
 +virSecLabelDriverPtr secLabelDriver;
  };
 
 and then initialized during qemud startup from qemudSecLabelInit().  
 
 During initialization, any available security labeling drivers are probed, 
 and the first one which thinks it should be used is installed. Top-level 
 libvirt API calls are then dispatched to the active security labeling 
 driver via the backend virt driver, as necessary.
 
 Note that the security labeling framework in this release is always 
 built-in -- it can be made a compile-time option later if desired.
 
 Requirements not yet addressed include:
 - Labeling of resources and generally comprehensive labeling management
 - Automatic labeling (e.g. for the simple isolation use-case)
 - Integration of labeling support into higher-level management tools such 
   as virt-manager
 - Integration with the audit subsystem to help with administration and 
   debugging
 - Domain of interpretation (DOI) checking/translation
 - Python bindings
 
 As mentioned, the goal at this stage is to get feedback on the underlying 
 design: comments welcome!
 
 
 - James
 -- 
 James Morris
 [EMAIL PROTECTED]


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [et-mgmt-tools] Copying Images for VMM

[Atsushi SAKAI]

Hello Bryan

I hope following page will help.
http://libvirt.org/apps.html

Thanks
Atsushi SAKAI



Bryan Christ [EMAIL PROTECTED] wrote:

 Please accept my apologies if this is not the right form for Virtual
 Machine Manager questions.
 
 I was wondering if someone could point me to documentation on image
 management.  In short I have WinXP guest machine on my laptop running on
 KVM and would like to copy that image to another computer.
 
 Thanks in advance,
 
 Bryan
 
 ___
 et-mgmt-tools mailing list
 et-mgmt-tools@redhat.com
 https://www.redhat.com/mailman/listinfo/et-mgmt-tools


___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Re: [et-mgmt-tools] [RFC]Re:[libvirt][RFC][PATCH]virt-managercallsmigration API

[Atsushi SAKAI]

Hi, Dan and Cole

I know you are very busy.
But would you give me a comment on this patch?

Thanks
Atsushi SAKAI




S.Sakamoto [EMAIL PROTECTED] wrote:

 Hi,
 
 As a result of migration test in my environment that applied this patch,
 there is not a problem.
 
 If not comment, please apply this patch.
 
 
 Thanks,
 Shigeki Sakamoto.
 
  Hi, Shigeki
  
  When you plan to post commit ready patch?
  
  Thanks
  Atsushi SAKAI
  
  
  S.Sakamoto [EMAIL PROTECTED] wrote:
  
   Hi,
   
   I make the prototype patch.
   
   This patch is displayed destination host in a sub-menu, as follows.
   
   right-click
 |
 +-  Run
 Pause
 Shutdown
 
 Migrate  host1.example.com
   host2.example.com
   host3.example.com
   
   The item that display in a sub-menu is the host
   which is a state of ACTIVE or INACTIVE besides the source host.
   When the host which is a state of ACTIVE or INACTIVE besides a source 
   host doesn't exist,
   (None) that is insensitive is displayed, as follows.
   
   right-click
 |
 +-  Run
 Pause
 Shutdown
 
 Migrate  (None)
   
   
domain.py  |6 
engine.py  |   36 
manager.py |   78 
   ++---
3 files changed, 117 insertions(+), 3 deletions(-)
   
   
   
   Thanks,
   Shigeki Sakamoto.
   
Hi, Daniel

Sorry for delaying response.

Thank you for your suggestions. I understand. 
I will make the prototype patch!

Thanks
Shigeki Sakamoto.

 On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote:
   
You probably want to send this to et-mgmt-list, which is where 
virt-manager
development happens,
   
   OK. For this, I tried to hear in et-mgmt-list.
   
  
  I'm sorry to be pressing, but would you give me a comment on this 
  patch for
  going on the next step to migrate from virt-manager ? 
  I attached screenshots this patch shows.
 
 I think rather than having it popup a new window with a list of hosts 
 to
 migrate to, you could just have a sub-menu where you choose the 
 destination
 host directly.
 
 eg,
 
 right-click
   |
   +-  Run
   Pause
   Shutdown
   
   Migrate  host1.example.com
 host2.example.com
 host3.example.com
 ...etc...
 
 When the user selects one of these hosts, it'd popup a confirmation
 window, and do the neccessary migration checks, and then allow the
 admin to confirm to start the migration.
 
I sent an e-mail last month with proposals for doing this 
within libvirt.  I put
up all of the information I have in the libvirt wiki here:

http://wiki.libvirt.org/page/TodoPreMigrationChecks
   
   Thank you for your information. I see above libvirt wiki and I 
   have a few 
   idea adding checks within libvirt. These point of view are Guest 
   and Host sanity
   in BASIC CHECKS. How about this points ?
   
1)Guest sanity is checking whether already existing or not on 
   the destination.
  Otherwise the uniqueness of the domain(UUID, name) are lost.
  * I think that it is right to check this in libvirt. How do 
   you think this ?
 
 Yes, checking for name/uuid uniqueness has to be done inside libvirt 
 by
 each hypervisor driver according to their own rules.
 
2)Host sanity is checking whether a migration flag is ON at each 
   virtualization.
 
 virt-manager will need to check the kind of things on the 
 TodoPreMigrationChecks
 wiki page.
 
 
 Daniel
 -- 
 |: Red Hat, Engineering, London   -o-   
 http://people.redhat.com/berrange/ :|
 |: http://libvirt.org  -o-  http://virt-manager.org  -o-  
 http://ovirt.org :|
 |: http://autobuild.org   -o- 
 http://search.cpan.org/~danberr/ :|
 |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 
 9505 :|
 
 ___
 et-mgmt-tools mailing list
 et-mgmt-tools@redhat.com
 https://www.redhat.com/mailman/listinfo/et-mgmt-tools

___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
  
  
  ___
  et-mgmt-tools mailing list
  et-mgmt-tools@redhat.com
  https://www.redhat.com/mailman/listinfo/et-mgmt-tools
  


___
et

Re: [libvirt] Libvirt support for migration in KVM

[Atsushi SAKAI]

Hi,

Please read following message.

https://www.redhat.com/archives/libvir-list/2008-September/msg00011.html

Thanks
Atsushi SAKAI







Shanmuga Rajan [EMAIL PROTECTED] wrote:

 Hi
 
 I have tested migration function VirDomain object by migrating with in
 localhost(for testing purpose).
 
 System details are
 
 KVM hypervisor.
 Intel VT 64 bit centos.
 libvirt 0.4.6. (compiled from source)
 vs i am running is Win 2003 64 bit...
 Host is also 64 bit
 
 but when i tried to use the migrate function of virDomain object. it
 throws the following error
 
 libvirt.libvirtError: virDomainMigrate() failed this function is not
 supported by the hypervisor: virDomainMigrate
 
 
 i read in kvm wiki that they do support  migration
 Can anyone point out the problem
 
 
 here comes the python code
 
  vsobj.migrate(conn,libvirt.VIR_MIGRATE_LIVE,None,conn.getURI(),0)
 libvir: error : this function is not supported by the hypervisor:
 virDomainMigrate
 Traceback (most recent call last):
   File stdin, line 1, in ?
   File /usr/lib64/python2.4/site-packages/libvirt.py, line 301, in migrate
 if ret is None:raise libvirtError('virDomainMigrate() failed', dom=self)
 libvirt.libvirtError: virDomainMigrate() failed this function is not
 supported by the hypervisor: virDomainMigrate
 
 
 
 
 Thanks for any suggestion
 
 -- Shan
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Suggestion on commit rules when fixing breakages

[Atsushi SAKAI]

Hi, Daniel

 This proposal seems approved.
Does this proposal message goes to somewhere in libvirt document?

Thanks
Atsushi SAKAI


Daniel Veillard [EMAIL PROTECTED] wrote:

   As the number of compilation options and platform grows, it gets
 more difficult for a commiter to always ensure one chunk of code
 won't give a problem in a different situation. To try to lower the
 cost of maintaining the protability I would suggest the following
 rule for commit:
   - if a recently commited patch breaks compilation on a platform
 or for a given driver then it's fine to commit a minimal fix
 directly without getting the review feedback first
   - similary if make check or make syntax-chek breaks, if there is
 an obvious fix, it's fine to commit immediately
 Note that this would remove the need to send the patch to the list
 anyway (or tell what the fix was if trivial). This doesn't either
 remove the rule that 'make check syntax-check' should pass before
 commiting anything, and obviously the existing review process is still
 needed t for anything which is not a trivial fix breaking make or
 checks.
 
   I guess it makes sense to minimize disruption for those working on
 head and lower the time needed to get those fix in for those who catch
 and fix them ;-)
   Opinions ?
 
 Daniel
 
 -- 
 Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
 [EMAIL PROTECTED]  | Rpmfind RPM search engine http://rpmfind.net/
 http://veillard.com/ | virtualization library  http://libvirt.org/
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Question about supporting other hypervisor

[Atsushi SAKAI]

Hello,

I have a simple question raised yesterday.

CIM(Common Information Model) is a kind of good I/F
(to support VMware, Hyper-V and other platform).

As a CIM Provider, libvirt-cim is going on.
But for CIM Client, Is not going on.

Is there any reason for not supporting CIM on libvirt driver layer?
I am thinking about cim-xml driver (like remote driver) in libvirt.

Ref.
http://www.dmtf.org/standards/wbem
http://en.wikipedia.org/wiki/Web-Based_Enterprise_Management

Thanks
Atsushi SAKAI



--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [et-mgmt-tools] [RFC]Re: [libvirt] [RFC][PATCH]virt-managercallsmigration API

[Atsushi SAKAI]

Hi, Shigeki

When you plan to post commit ready patch?

Thanks
Atsushi SAKAI


S.Sakamoto [EMAIL PROTECTED] wrote:

 Hi,
 
 I make the prototype patch.
 
 This patch is displayed destination host in a sub-menu, as follows.
 
 right-click
   |
   +-  Run
   Pause
   Shutdown
   
   Migrate  host1.example.com
 host2.example.com
 host3.example.com
 
 The item that display in a sub-menu is the host
 which is a state of ACTIVE or INACTIVE besides the source host.
 When the host which is a state of ACTIVE or INACTIVE besides a source host 
 doesn't exist,
 (None) that is insensitive is displayed, as follows.
 
 right-click
   |
   +-  Run
   Pause
   Shutdown
   
   Migrate  (None)
 
 
  domain.py  |6 
  engine.py  |   36 
  manager.py |   78 
 ++---
  3 files changed, 117 insertions(+), 3 deletions(-)
 
 
 
 Thanks,
 Shigeki Sakamoto.
 
  Hi, Daniel
  
  Sorry for delaying response.
  
  Thank you for your suggestions. I understand. 
  I will make the prototype patch!
  
  Thanks
  Shigeki Sakamoto.
  
   On Fri, Sep 19, 2008 at 06:43:37PM +0900, S.Sakamoto wrote:
 
  You probably want to send this to et-mgmt-list, which is where 
  virt-manager
  development happens,
 
 OK. For this, I tried to hear in et-mgmt-list.
 

I'm sorry to be pressing, but would you give me a comment on this patch 
for
going on the next step to migrate from virt-manager ? 
I attached screenshots this patch shows.
   
   I think rather than having it popup a new window with a list of hosts to
   migrate to, you could just have a sub-menu where you choose the 
   destination
   host directly.
   
   eg,
   
   right-click
 |
 +-  Run
 Pause
 Shutdown
 
 Migrate  host1.example.com
   host2.example.com
   host3.example.com
   ...etc...
   
   When the user selects one of these hosts, it'd popup a confirmation
   window, and do the neccessary migration checks, and then allow the
   admin to confirm to start the migration.
   
  I sent an e-mail last month with proposals for doing this within 
  libvirt.  I put
  up all of the information I have in the libvirt wiki here:
  
  http://wiki.libvirt.org/page/TodoPreMigrationChecks
 
 Thank you for your information. I see above libvirt wiki and I have a 
 few 
 idea adding checks within libvirt. These point of view are Guest and 
 Host sanity
 in BASIC CHECKS. How about this points ?
 
  1)Guest sanity is checking whether already existing or not on the 
 destination.
Otherwise the uniqueness of the domain(UUID, name) are lost.
* I think that it is right to check this in libvirt. How do you 
 think this ?
   
   Yes, checking for name/uuid uniqueness has to be done inside libvirt by
   each hypervisor driver according to their own rules.
   
  2)Host sanity is checking whether a migration flag is ON at each 
 virtualization.
   
   virt-manager will need to check the kind of things on the 
   TodoPreMigrationChecks
   wiki page.
   
   
   Daniel
   -- 
   |: Red Hat, Engineering, London   -o-   
   http://people.redhat.com/berrange/ :|
   |: http://libvirt.org  -o-  http://virt-manager.org  -o-  
   http://ovirt.org :|
   |: http://autobuild.org   -o- 
   http://search.cpan.org/~danberr/ :|
   |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 
   9505 :|
   
   ___
   et-mgmt-tools mailing list
   et-mgmt-tools@redhat.com
   https://www.redhat.com/mailman/listinfo/et-mgmt-tools
  
  ___
  et-mgmt-tools mailing list
  et-mgmt-tools@redhat.com
  https://www.redhat.com/mailman/listinfo/et-mgmt-tools


___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Re: [libvirt] openvz support in libvirt

[Atsushi SAKAI]

Hi,

About libvirt functionality for openVZ.
see the struct openvzDriver in libvirt/src/openvz_driver.c
(around line 957)
http://git.et.redhat.com/?p=libvirt.git;a=blob;f=src/openvz_driver.c

Thanks
Atsushi SAKAI

Anton Protopopov [EMAIL PROTECTED] wrote:

 Hello.
 
 To start with, I have the following questions:
 
 Does libvirt support the xml format for openvz driver described in the next
 thread?
 http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html
 (I think, that it does not. But will it support it in future? :))
 
 What libvirt functionality does openvz driver support?
 (Openvz does not mentioned in http://libvirt.org/hvsupport.html)
 
 Anton.


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [Qemu-devel] [PATCH 0/10] Live migration for QEMU

[Atsushi SAKAI]

Hi,

It may be stupid question.
This migration is SMP aware?

Thanks
Atsushi SAKAI

Anthony Liguori [EMAIL PROTECTED] wrote:

 This series adds live migration support to QEMU.  It's inspired by the
 implementation of live migration in KVM, but at this point, is almost
 a full rewrite.  Uri Lublin did a large amount of the work on the live
 migration implementation in KVM.
 
 This patch series is not yet ready to apply.  There are a few FIXMEs
 and I have to add back support for restoring v2 saved images.  I wanted
 to get these patches out on the list though for review since it's a rather
 large series.
 
 Live migration will work with any target that supports save/restore.
 
 


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [libvirt] libvirt vs XenAPI

[Atsushi SAKAI]

Hi, Alain

I guess  Daniel says xend issue.(since it relates to XenAPI)
As for hypervisor, You are correct in RHEL5.2 and CentOS5.2.

Current RHEL/Xen is very complex compared to upstream Xen.

Thanks
Atsushi SAKAI



Alain Barthe [EMAIL PROTECTED] wrote:

 2008/9/4 Daniel Veillard [EMAIL PROTECTED]
 
  On Tue, Sep 02, 2008 at 06:09:43PM +0200, atif bajwa wrote:
   Just quick question,
   what version of Xen/XenApi is packaged in RHEL 5.1/5.2. Can I remotely
   access it using XML-RPC API or not?
 
RHEL-5.2 has xen-3.0.3, and that will stay the same for the lifetime
  of RHEL5. There is no XenAPI for this, as Dan Berrange told you
  already. And for remote access you have libvirt support.
 
 
 On CentOS-5.2 (same as RedHat, IFAIK), xen is 3.1.2. Don't believe rpm
 version, check xm info instead.
 
 
 
 
  Daniel
 
  --
  Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
  [EMAIL PROTECTED]  | Rpmfind RPM search engine http://rpmfind.net/
  http://veillard.com/ | virtualization library  http://libvirt.org/
 
  --
  Libvir-list mailing list
  Libvir-list@redhat.com
  https://www.redhat.com/mailman/listinfo/libvir-list
 


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirtd needs to be always running/

[Atsushi SAKAI]

Hi, Yao

  You should differenciate Qemu and Xen(zen).
  
  For QEMU, libvirtd need to run always.
For Xen,  it does not requrired to run for local machine. and required to run 
for remote machine.

Thanks
Atsushi SAKAI


Yushu Yao [EMAIL PROTECTED] wrote:

 Hi All,
 
 A newbie question:
 Does the libvirtd need to be running all the time if I want to use any
 functions of libvirt (as simple as start/stop/pause my virtual machines
 (qemu/zen)). Or is it only try if I use the remote functions or virsh.
 
 Thanks,
 -Yushu
 
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirtd needs to be always running/

[Atsushi SAKAI]

Yushu Yao [EMAIL PROTECTED] wrote:

 Thanks Atsushi and Stefan,
 
 It seems that libvirtd has to run with root, is this true?
Yes

 
 But why does libvirtd need to run for QEMU? If it's for start/stop/pause vm,
 is Qemu's command line tool not enough?

Please see follows
https://www.redhat.com/archives/libvir-list/2008-September/msg5.html

 
 Thanks!
 
 -Yushu
 
 
 
 On 9/3/08 6:08 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Atsushi SAKAI schreef:
You should differenciate Qemu and Xen(zen).

For QEMU, libvirtd need to run always.
  For Xen,  it does not requrired to run for local machine. and required to 
  run
  for remote machine.
  
  
  Some people still have their hopes that libvirtd will do the same for
  Xen in the near future :)
  
  
  Stefan
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v2.0.9 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
  
  iEUEARECAAYFAki/NP8ACgkQYH1+F2Rqwn32awCXdiNGVwZWj3dEA526BZDOM2Zh
  qwCeOGf7fQmG9pzG7tKKuuL7ZzMT18c=
  =+umj
  -END PGP SIGNATURE-
 
 


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] libvirt vs XenAPI

[Atsushi SAKAI]

Hi, Atif

If you want to natively use Xen API,
I will recommend to use it directly.
If you want to use archtecture neutral API,
You should use libvirt.


Libvirt pros and cons
pros:any Xen version is supported (like 3.y.z or 2.y)
cons:architecuture neutral API. specific functionality is not always supported.

And this list may be helpful.
http://libvirt.org/hvsupport.html

Thanks
Atsushi SAKAI


atif bajwa [EMAIL PROTECTED] wrote:

 Hi!
 
 I am looking to integrate the Xen Management. Please guide me advantages of
 using libvirt over XenAPI and please list xen-based-hypervisor
 distributions(versions) that will be supported with libvirt. And what is
 future of libvirt as XenSource is more focused on XenAPI.
 
 Regards,
 Atif


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Remote access from libvirt windows client

[Atsushi SAKAI]

Hi, Atif

At this moment, 0.4.4 is not working correctly.
Hourly cvs-snapshot is better solution.
http://libvirt.org/downloads.html

If you want to compile on MinGW, Please see following Mail.
https://www.redhat.com/archives/libvir-list/2008-June/msg00145.html

If you want to compile on Cygwin,
You should turn off HAVE_WINSOCK2_H after autogen.sh


Thanks
Atsushi SAKAI


atif bajwa [EMAIL PROTECTED] wrote:

 Hi!
 
 I am looking to add support for Xen. Please guide me which is best method to
 connect to remote system(host) from windows client. What privileges and
 binaries will be required for client program to read data only.
 
 If possible please list supported libvirt versions that can be port to
 windows. Also list xen-based-hypervisor distributions that I can get remote
 access with libvirt windows based client.
 
 Regards,
 Atif


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Question about migration on KVM/Qemu

[Atsushi SAKAI]

Hi, Chris

Thanks for your reply.

Please let me clearify,
You mean oVirt does not support migration at this moment,
Since Migration of KVM/Qemu is not supported on libvirt.

Thanks
Atsushi SAKAI


Chris Lalancette [EMAIL PROTECTED] wrote:

 Atsushi SAKAI wrote:
  Hi,
  
  I have a question about migration on KVM/Qemu.
 From src/qemu_driver.c, domainMigrateX is not defined.
  
  But from news on 0.3.2, KVM migration is supported.
  http://libvirt.org/news.html
  
  Where is the code which performs migration on KVM/Qemu.
 
 Hm, that's a little odd.  As far as I know, KVM migration isn't supported yet.
 
 There are some patches from Rich Jones (that he's posted a few times), but 
 there
 is a bug in upstream KVM that prevents them from working properly.
 Unfortunately, upstream KVM/Qemu have decided to re-do their implementation of
 migration, so we can't commit to Rich Jones' patches until that gets sorted
 upstream.
 
 Chris Lalancette


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Exposing some unique features?

[Atsushi SAKAI]

Hi, Quynh

Thank you for your comment.
I am clearified your question.
But I have no good idea to solve.
Someone may have a good idea.

Thanks
Atsushi SAKAI



Nguyen Anh Quynh [EMAIL PROTECTED] wrote:

 On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI [EMAIL PROTECTED] wrote:
  Hi, Quynh
 
  Did you see the libvirt access control feature?
  http://libvirt.org/auth.html
  You mean current access control feature is not enough for your use.
 
 But that access control is about authenticating/authorizing, and that
 has nothing to do with the idea of exposing unique features.
 
 Thanks,
 Q
 
 
 
  Nguyen Anh Quynh [EMAIL PROTECTED] wrote:
 
  Hi,
 
  Though libvirt tries very hard to hide the difference between
  hypervisors behind an abstraction layer, there are still differences
  that we might want to expose to the users. For example, QEMU has the
  monitor interface, which provides some unique functions. Users might
  want to have access to the monitor interface and send command to it
  (like gdbserver command?).
 
  So how can we expose such information? We can have a new driver
  function, which return an opaque structure. The content of the
  structure is of course depends on the hypervisor type.
 
  One problem is that this might be dangerous if users relies on the
  QEMU monitor to execute some functions that should be done under
  control.
 
  Idea?
 
  Thanks,
  Quynh
 
  --
  Libvir-list mailing list
  Libvir-list@redhat.com
  https://www.redhat.com/mailman/listinfo/libvir-list
 
 
 


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Use gcc style for structure fields declaration

[Atsushi SAKAI]

Hi, Quynh

Good catch!
 +1

Thanks
Atsushi SAKAI


Nguyen Anh Quynh [EMAIL PROTECTED] wrote:

 Hi,
 
 This patch uses gcc style to declare fields in virDriver structures.
 This also makes it easier to spot bugs.
 
 $ diffstat fix3.patch
  lxc_driver.c|  118 ++--
  openvz_driver.c |  118 ++--
  qemu_driver.c   |  126 
 
  test.c  |  118 ++--
  4 files changed, 240 insertions(+), 240 deletions(-)
 
 
 Thanks,
 Quynh


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Exposing some unique features?

[Atsushi SAKAI]

Hi, Quynh

Did you see the libvirt access control feature?
http://libvirt.org/auth.html
You mean current access control feature is not enough for your use.


Thanks
Atsushi SAKAI





Nguyen Anh Quynh [EMAIL PROTECTED] wrote:

 Hi,
 
 Though libvirt tries very hard to hide the difference between
 hypervisors behind an abstraction layer, there are still differences
 that we might want to expose to the users. For example, QEMU has the
 monitor interface, which provides some unique functions. Users might
 want to have access to the monitor interface and send command to it
 (like gdbserver command?).
 
 So how can we expose such information? We can have a new driver
 function, which return an opaque structure. The content of the
 structure is of course depends on the hypervisor type.
 
 One problem is that this might be dangerous if users relies on the
 QEMU monitor to execute some functions that should be done under
 control.
 
 Idea?
 
 Thanks,
 Quynh
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Re: [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-basedvirtualization

[Atsushi SAKAI]

Hi, James

  Thank you for posting the announcement.
  This thread is very interesting.
Instead, I understand many things to be dicided.

- Utilize the new hierarchical types being proposed upstream by
  NEC.  (No analysis done yet).
Would you point the following document?


Thanks
Atsushi SAKAI




--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] fix minor typo

[Atsushi SAKAI]

Hi, John

Thank you for your suggestion.
I am looking around the libvirt.pot and found 4 typos additionally.
I am pushing these fixes.

Thanks
Atsushi SAKAI


John Levon [EMAIL PROTECTED] wrote:

 
 Fix a typo in the message for the 'dump' command in virsh.
 
 Signed-off-by: John Levon [EMAIL PROTECTED]
 
 
 Index: src/virsh.c
 ===
 RCS file: /data/cvs/libvirt/src/virsh.c,v
 retrieving revision 1.157
 diff -u -r1.157 virsh.c
 --- src/virsh.c   22 Jul 2008 16:12:01 -  1.157
 +++ src/virsh.c   13 Aug 2008 15:50:09 -
 @@ -1320,7 +1320,7 @@
  return FALSE;
  
  if (virDomainCoreDump(dom, to, 0) == 0) {
 -vshPrint(ctl, _(Domain %s dumpd to %s\n), name, to);
 +vshPrint(ctl, _(Domain %s dumped to %s\n), name, to);
  } else {
  vshError(ctl, FALSE, _(Failed to core dump domain %s to %s),
   name, to);
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


fix_message_20080815.patch
Description: Binary data
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Question about html file in docs

[Atsushi SAKAI]

Hi, Daniel

If I run the make on libvirt,
cvs diff outputs large diffs on html.
This is because the difference of html and html.in is large.

I think it should be fixed.
How do you think?

Thanks
Atsushi SAKAI


Daniel Veillard [EMAIL PROTECTED] wrote:

 On Wed, Aug 13, 2008 at 09:56:00AM +0900, Atsushi SAKAI wrote:
  Hi,
  
  I think html files in docs directory are redundunt.
  It is because html file is created by html.in.
  May I remove these files?
 
  No
 
  Or are there any reason about staying these files?
 
  Because the web site is a CVS checkout of the docs/ subdir
 
 Daniel
 
 -- 
 Red Hat Virtualization group http://redhat.com/virtualization/
 Daniel Veillard  | virtualization library  http://libvirt.org/
 [EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
 http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] check for XHTML1 DTDs availability

[Atsushi SAKAI]

Hi, Daniel

  I need to set http_proxy on my environment.
(Sorry, since I need not set http_proxy since I use wget and cvs only)
But still stays large diffs on html 6 files.

drvqemu.html
formatnetwork.html
formatstorage.html
intro.html
news.html
remote.html

Thanks
Atsushi SAKAI



Daniel Veillard [EMAIL PROTECTED] wrote:

 On Wed, Aug 13, 2008 at 08:10:36AM -0400, Daniel Veillard wrote:
Well apparently the XSL output is post-processed by xmlling --valid 
  --format
  which then introduce a dependancy on the XHTML1 DTDs . If you don't have 
  them
  installed locally you will get validation error messages when building
  in docs and the output will diverge.
  
The simplest solution for you is probably to make sure you have XHTML1
  DTDs installed in your local XML catalog, which on RHEL/Fedora is as simple
  as having the package xhtml1-dtds installed on your machine(s).
 
   The patch enclosed adds detection for the XHTML1 dtds at runtime on the 
 build machine, and should solve the problem of diverging docs, replace the
 XML validity warnings by a more general message and add the requirement
 when building the RPM. I guess this should solve the issue
 
 Daniel
 
 -- 
 Red Hat Virtualization group http://redhat.com/virtualization/
 Daniel Veillard  | virtualization library  http://libvirt.org/
 [EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
 http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Question about html file in docs

[Atsushi SAKAI]

Hi,

I think html files in docs directory are redundunt.
It is because html file is created by html.in.
May I remove these files?
Or are there any reason about staying these files?

Thanks
Atsushi SAKAI



--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] fix MinGW compilation(200808)

[Atsushi SAKAI]

Hi, Jim

I am looking around the code about WEXITSTATUS.
It seems that following kind of code needs on gnulib.
http://kerneltrap.org/mailarchive/git/2008/2/27/1003054
What do you think?

Thanks
Atsushi SAKAI



Atsushi SAKAI [EMAIL PROTECTED] wrote:

 Hi, Dan
 
 mkstemp is solved by Jim.
 
 But WEXITSTATUS problem is not solved yet.
 Since sys/wait.h does not exist on MinGW.
 http://www.mingw.org/MinGWiki/index.php/PortingChildren
 
 Thanks
 Atsushi SAKAI
 
 
 
 
 Daniel P. Berrange [EMAIL PROTECTED] wrote:
 
  On Thu, Aug 07, 2008 at 05:56:48PM +0900, Atsushi SAKAI wrote:
   Hi, Jim
   
   Your patch works fine. It passes inet_pton problem.
   Please apply it.
   
   By the way, virsh compilation error.
   Is threre any good suggestion?
   =
   virsh-virsh.o: In function `editWriteToTempFile':
   C:/msys/1.0/home/Administrator/work/libvirt/src/virsh.c:5080: undefined 
   reference to `mkstemp'
  
  Look like there is a gnulib module for that - Jim could say if its license
  compatible
  
   virsh-virsh.o: In function `editFile':
   C:/msys/1.0/home/Administrator/work/libvirt/src/virsh.c:5155: undefined 
   reference to `WEXITSTATUS'
  
  virsh.c seems to be missing  '#include sys/wait.h'
  
  Daniel
  -- 
  |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ 
  :|
  |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org 
  :|
  |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ 
  :|
  |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 
  :|
 
 
 --
 Libvir-list mailing list
 Libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list