Mailing List Archive

Awesome. will do.

On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
<doug.hellmann@dreamhost.com> wrote:
> I have started creating blueprints from my notes about activities we need to
> complete for the unified CLI. Please check the list
> at https://blueprints.launchpad.net/python-openstackclient/ and make sure I
> haven't missed anything that has been discussed so far, and open a blueprint
> if I have.
>
> Thanks,
> Doug
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Question do we want to consider an interactive mode on the CLI? Or is
the shell enough for our use case?

Maybe just ignore that question until we've got something beyond the basics.

-Matt

On Tue, May 1, 2012 at 4:34 PM, Matt Joyce <matt@nycresistor.com> wrote:
> Awesome. will do.
>
> On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
> <doug.hellmann@dreamhost.com> wrote:
>> I have started creating blueprints from my notes about activities we need to
>> complete for the unified CLI. Please check the list
>> at https://blueprints.launchpad.net/python-openstackclient/ and make sure I
>> haven't missed anything that has been discussed so far, and open a blueprint
>> if I have.
>>
>> Thanks,
>> Doug
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

I borrowed Guido's time machine and added an interactive mode to cliff this
weekend.

http://cliff.readthedocs.org/en/latest/index.html

On Tue, May 1, 2012 at 7:48 PM, Matt Joyce <matt@nycresistor.com> wrote:

> Question do we want to consider an interactive mode on the CLI? Or is
> the shell enough for our use case?
>
> Maybe just ignore that question until we've got something beyond the
> basics.
>
> -Matt
>
> On Tue, May 1, 2012 at 4:34 PM, Matt Joyce <matt@nycresistor.com> wrote:
> > Awesome. will do.
> >
> > On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
> > <doug.hellmann@dreamhost.com> wrote:
> >> I have started creating blueprints from my notes about activities we
> need to
> >> complete for the unified CLI. Please check the list
> >> at https://blueprints.launchpad.net/python-openstackclient/ and make
> sure I
> >> haven't missed anything that has been discussed so far, and open a
> blueprint
> >> if I have.
> >>
> >> Thanks,
> >> Doug
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >>
>

So. I see that now. ( got a devstack vm setup with trunk build )

Do we want the interactive mode to engage by default when executing
without parameters? Or do we want a flag to engage that ( people can
alias on their own if they want ).

-Matt

On Tue, May 1, 2012 at 4:52 PM, Doug Hellmann
<doug.hellmann@dreamhost.com> wrote:
> I borrowed Guido's time machine and added an interactive mode to cliff this
> weekend.
>
> http://cliff.readthedocs.org/en/latest/index.html
>
>
> On Tue, May 1, 2012 at 7:48 PM, Matt Joyce <matt@nycresistor.com> wrote:
>>
>> Question do we want to consider an interactive mode on the CLI?  Or is
>> the shell enough for our use case?
>>
>> Maybe just ignore that question until we've got something beyond the
>> basics.
>>
>> -Matt
>>
>> On Tue, May 1, 2012 at 4:34 PM, Matt Joyce <matt@nycresistor.com> wrote:
>> > Awesome. will do.
>> >
>> > On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
>> > <doug.hellmann@dreamhost.com> wrote:
>> >> I have started creating blueprints from my notes about activities we
>> >> need to
>> >> complete for the unified CLI. Please check the list
>> >> at https://blueprints.launchpad.net/python-openstackclient/ and make
>> >> sure I
>> >> haven't missed anything that has been discussed so far, and open a
>> >> blueprint
>> >> if I have.
>> >>
>> >> Thanks,
>> >> Doug
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~openstack
>> >> Post to     : openstack@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~openstack
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

I thought having it run like that by default made sense, but if the list
agrees we want a flag I'm happy to change it.

On Tue, May 1, 2012 at 8:06 PM, Matt Joyce <matt@nycresistor.com> wrote:

> So. I see that now. ( got a devstack vm setup with trunk build )
>
> Do we want the interactive mode to engage by default when executing
> without parameters? Or do we want a flag to engage that ( people can
> alias on their own if they want ).
>
> -Matt
>
> On Tue, May 1, 2012 at 4:52 PM, Doug Hellmann
> <doug.hellmann@dreamhost.com> wrote:
> > I borrowed Guido's time machine and added an interactive mode to cliff
> this
> > weekend.
> >
> > http://cliff.readthedocs.org/en/latest/index.html
> >
> >
> > On Tue, May 1, 2012 at 7:48 PM, Matt Joyce <matt@nycresistor.com> wrote:
> >>
> >> Question do we want to consider an interactive mode on the CLI? Or is
> >> the shell enough for our use case?
> >>
> >> Maybe just ignore that question until we've got something beyond the
> >> basics.
> >>
> >> -Matt
> >>
> >> On Tue, May 1, 2012 at 4:34 PM, Matt Joyce <matt@nycresistor.com>
> wrote:
> >> > Awesome. will do.
> >> >
> >> > On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
> >> > <doug.hellmann@dreamhost.com> wrote:
> >> >> I have started creating blueprints from my notes about activities we
> >> >> need to
> >> >> complete for the unified CLI. Please check the list
> >> >> at https://blueprints.launchpad.net/python-openstackclient/ and make
> >> >> sure I
> >> >> haven't missed anything that has been discussed so far, and open a
> >> >> blueprint
> >> >> if I have.
> >> >>
> >> >> Thanks,
> >> >> Doug
> >> >>
> >> >> _______________________________________________
> >> >> Mailing list: https://launchpad.net/~openstack
> >> >> Post to : openstack@lists.launchpad.net
> >> >> Unsubscribe : https://launchpad.net/~openstack
> >> >> More help : https://help.launchpad.net/ListHelp
> >> >>
> >
> >
>

By default sounds fine to me as long as there is a banner printed when
entering interactive mode which explains how to get help and (directly
and/or via the help) how to quit.

Doug Hellmann (doug.hellmann@dreamhost.com) wrote:
> I thought having it run like that by default made sense, but if the list
> agrees we want a flag I'm happy to change it.
>
> On Tue, May 1, 2012 at 8:06 PM, Matt Joyce <matt@nycresistor.com> wrote:
>
> > So. I see that now. ( got a devstack vm setup with trunk build )
> >
> > Do we want the interactive mode to engage by default when executing
> > without parameters? Or do we want a flag to engage that ( people can
> > alias on their own if they want ).
> >
> > -Matt

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Doug Hellmann (doug.hellmann@dreamhost.com) wrote:
> I have started creating blueprints from my notes about activities we need
> to complete for the unified CLI. Please check the list at
> https://blueprints.launchpad.net/python-openstackclient/

Cool. Presumably we don't need to wait until the next summit to have
these approved? http://wiki.openstack.org/Process and the majority of
http://wiki.openstack.org/BlueprintsLifecycle suggests we would, but
the latter gives the meaning of the 'Discussion' value of the
'Definition' field as "Blueprint will be discussed at the design
summit or on the ML" which suggests that there is some flexibility
about whether blueprint lifecycles have to revolve around design
summits.

> and make sure I haven't missed anything that has been discussed so
> far, and open a blueprint if I have.

Is it worth having one for bash/zsh completion? It seems that there
is some prior art here:

https://bugs.launchpad.net/keystone/+bug/936423

and as you may have seen, one of my SUSE colleagues advertised some
new bash completion code elsewhere on this list today:

https://lists.launchpad.net/openstack/msg10991.html

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

going into interactive mode when no args are specified works well for virsh.

Vish

On May 1, 2012, at 8:08 PM, Doug Hellmann wrote:

> I thought having it run like that by default made sense, but if the list agrees we want a flag I'm happy to change it.
>
> On Tue, May 1, 2012 at 8:06 PM, Matt Joyce <matt@nycresistor.com> wrote:
> So. I see that now. ( got a devstack vm setup with trunk build )
>
> Do we want the interactive mode to engage by default when executing
> without parameters? Or do we want a flag to engage that ( people can
> alias on their own if they want ).
>
> -Matt
>
> On Tue, May 1, 2012 at 4:52 PM, Doug Hellmann
> <doug.hellmann@dreamhost.com> wrote:
> > I borrowed Guido's time machine and added an interactive mode to cliff this
> > weekend.
> >
> > http://cliff.readthedocs.org/en/latest/index.html
> >
> >
> > On Tue, May 1, 2012 at 7:48 PM, Matt Joyce <matt@nycresistor.com> wrote:
> >>
> >> Question do we want to consider an interactive mode on the CLI? Or is
> >> the shell enough for our use case?
> >>
> >> Maybe just ignore that question until we've got something beyond the
> >> basics.
> >>
> >> -Matt
> >>
> >> On Tue, May 1, 2012 at 4:34 PM, Matt Joyce <matt@nycresistor.com> wrote:
> >> > Awesome. will do.
> >> >
> >> > On Tue, May 1, 2012 at 1:47 PM, Doug Hellmann
> >> > <doug.hellmann@dreamhost.com> wrote:
> >> >> I have started creating blueprints from my notes about activities we
> >> >> need to
> >> >> complete for the unified CLI. Please check the list
> >> >> at https://blueprints.launchpad.net/python-openstackclient/ and make
> >> >> sure I
> >> >> haven't missed anything that has been discussed so far, and open a
> >> >> blueprint
> >> >> if I have.
> >> >>
> >> >> Thanks,
> >> >> Doug
> >> >>
> >> >> _______________________________________________
> >> >> Mailing list: https://launchpad.net/~openstack
> >> >> Post to : openstack@lists.launchpad.net
> >> >> Unsubscribe : https://launchpad.net/~openstack
> >> >> More help : https://help.launchpad.net/ListHelp
> >> >>
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

On Wed, May 2, 2012 at 10:39 AM, Adam Spiers <aspiers@suse.com> wrote:

> Doug Hellmann (doug.hellmann@dreamhost.com) wrote:
> > I have started creating blueprints from my notes about activities we need
> > to complete for the unified CLI. Please check the list at
> > https://blueprints.launchpad.net/python-openstackclient/
>
> Cool. Presumably we don't need to wait until the next summit to have
> these approved? http://wiki.openstack.org/Process and the majority of
> http://wiki.openstack.org/BlueprintsLifecycle suggests we would, but
> the latter gives the meaning of the 'Discussion' value of the
> 'Definition' field as "Blueprint will be discussed at the design
> summit or on the ML" which suggests that there is some flexibility
> about whether blueprint lifecycles have to revolve around design
> summits.
>

Maybe I'm doing this wrong. I wanted to make a list of the things I know we
have to do, so people who don't have access to the inside of my head can
divy up the list (that's a short list). These things are "features" not
"bugs" so I thought blueprints was the right way to go.

In any case, yes, I consider it safe to work on all of these items now.


>
> > and make sure I haven't missed anything that has been discussed so
> > far, and open a blueprint if I have.
>
> Is it worth having one for bash/zsh completion? It seems that there
> is some prior art here:
>
> https://bugs.launchpad.net/keystone/+bug/936423


I am counting generating the completion data for bash and other shells as a
core feature of cliff. That's not an OpenStack incubated project per se, so
I put those items in github issues under that project (
https://github.com/dreamhost/cliff). I welcome any and all contributions
there, too.


> and as you may have seen, one of my SUSE colleagues advertised some
> new bash completion code elsewhere on this list today:
>
> https://lists.launchpad.net/openstack/msg10991.html


I hadn't seen that yet, but I will take a look so thanks for the pointer.

Doug

On Wed, May 2, 2012 at 10:18 AM, Doug Hellmann
<doug.hellmann@dreamhost.com> wrote:
> Maybe I'm doing this wrong. I wanted to make a list of the things I know we
> have to do, so people who don't have access to the inside of my head can
> divy up the list (that's a short list). These things are "features" not
> "bugs" so I thought blueprints was the right way to go.

It's fine to log to-dos as bugs especially if they're not big changes.
Blueprints are generally used to outline larger changes/features/etc.
They get prioritized, and assigned like bugs but also have the
ability to target them to future releases (we don't have any set up
yet).

For example, the api-versioning should outline the implementation of
handling multiple API versions. devstack-integration could have been
a bug; that can also be assigned to the devstack project and tracked
to a review when it is closed.

I did a quick prioritization pass on the blueprints just now.

dt

--

Dean Troyer
dtroyer@gmail.com

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

I skipped out on blue printing and just submitted a gerrit review for
adding argparse flags for specifying URL for specific APIs.

Is that cool or do we want blue prints at that level of low complexity?

-Matt

On Wed, May 2, 2012 at 10:13 AM, Dean Troyer <dtroyer@gmail.com> wrote:
> On Wed, May 2, 2012 at 10:18 AM, Doug Hellmann
> <doug.hellmann@dreamhost.com> wrote:
>> Maybe I'm doing this wrong. I wanted to make a list of the things I know we
>> have to do, so people who don't have access to the inside of my head can
>> divy up the list (that's a short list). These things are "features" not
>> "bugs" so I thought blueprints was the right way to go.
>
> It's fine to log to-dos as bugs especially if they're not big changes.
>  Blueprints are generally used to outline larger changes/features/etc.
>  They get prioritized, and assigned like bugs but also have the
> ability to target them to future releases (we don't have any set up
> yet).
>
> For example, the api-versioning should outline the implementation of
> handling multiple API versions.  devstack-integration could have been
> a bug; that can also be assigned to the devstack project and tracked
> to a review when it is closed.
>
> I did a quick prioritization pass on the blueprints just now.
>
> dt
>
> --
>
> Dean Troyer
> dtroyer@gmail.com
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

On Wed, May 2, 2012 at 1:51 PM, Matt Joyce <matt@nycresistor.com> wrote:
> I skipped out on blue printing and just submitted a gerrit review for
> adding argparse flags for specifying URL for specific APIs.

Why is this needed? These URLs come from the service catalog. Cases
where you do need to override that use --os-url as part of token flow
auth, skipping the service catalog.

> Is that cool or do we want blue prints at that level of low complexity?

There should be some sort of discussion for design changes/additions.
Blueprints are a way to do that and record the discussion and
target/track the work. These discussions do happen in the Gerrit
review comments too, but those are more reactive than proactive.

BTW, rather than abandon your initial change, you could have made the
update, commited with 'git commit -a --amend' and push a new patchset
with 'git review'. As long as the change id in the log message
doesn't change Gerrit does the Right Thing. See the bottom of
http://wiki.openstack.org/GerritWorkflow for details.

dt

--

Dean Troyer
dtroyer@gmail.com

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

>> I skipped out on blue printing and just submitted a gerrit review for
>> adding argparse flags for specifying URL for specific APIs.
>
> Why is this needed?  These URLs come from the service catalog.  Cases
> where you do need to override that use --os-url as part of token flow
> auth, skipping the service catalog.

I was thinking of edge cases where someone may want to target a query
to a specific api server. Diagnostics stuff. Maybe we don't want to
add this now. Seemed simple enough though. Might be too much detail
work.

>> Is that cool or do we want blue prints at that level of low complexity?
>
> There should be some sort of discussion for design changes/additions.
> Blueprints are a way to do that and record the discussion and
> target/track the work.  These discussions do happen in the Gerrit
> review comments too, but those are more reactive than proactive.

Okay. I'll create a blue print. Just seemed such a simple change we
could vote it up or down in gerrit directly.

> BTW, rather than abandon your initial change, you could have made the
> update, commited with 'git commit -a --amend' and push a new patchset
> with 'git review'.  As long as the change id in the log message
> doesn't change Gerrit does the Right Thing.  See the bottom of
> http://wiki.openstack.org/GerritWorkflow for details.

Yes, sorry about failing to amend. Still getting acquainted with
gerrit. Already been informed of that.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp